[LAD] pipewire

[Fons Adriaensen]

Hello, Wim,

> Sorry, git for now. I just started to implement the last bits to make a
> session manager optional.

OK, I'll wait until this is available via Arch (don't want to mix up
two potential problems, build/install and configure...)
 

> All alsa devices are wrapped in an adapter. This contains:
> 
>    -> channelmix -> resample -> convert -> alsa-device
> 
> channelmix and resample are disabled when the graph sample rate
> and  device channels all match the adapter ports, you would configure
> the same number of channels on the output as the alsa-device channels
> and set the graph rate to something the hw supports.

In the example config, node.param.Portconfig.format.channels is
hardcoded. Is there a way to obtain the number of channels the
device supports (to make sure the values match) ? ALSA does
provide this info once the devide is opened...

What will happen if the configured number of channels does not
match ? What sort of channelmix will I get ? 

> The channelmix is mostly to support making a 5.1 sink that can downmix
> to dolby or some other tricks.

This can be a very devious thing. I remember an occcasion some
years ago (when I was in Parma) when some students were doing
measurements in a rented anechoic room during an entire week.
Later, when the measurements were processed, they discovered
that all of them were useless because their (Windows) system
had been trying to be clever and had applied gain changes and
channel mixing without them being aware. Now work out the cost
of renting an anechoic room for 60 hours. Plus, if they hadn't
been students and 'free labour', the consultancy fees for the
same period.

For any serious work, there are things that need to be
disabled without any chance of them ever be re-enabled by
accident. The required result when something does not match
is to fail and report, not to try and be clever and 'fix'
things behind the user's back.

The idea of having the daemon do the 'plumbing' and the 
session manager to define 'policies' is a very good one. 
But to take that to its logical consequence, the defaults
for any optional processing (channel gains and mixing,
resampling,...) should be off and disabled. If any other
defaults make sense for the 'average user', they should
be defaults defined by the session manager, not by the
plumbing daemon. 


There is one feature that would be very desirable and
for which I would even be prepared to write an ad-hoc
session manager if that is the only place it can be
done: if a sound card becomes unavailable while in use,
substitute a dummy device with the same sample rate,
period, and number of channels, so the entire processing
graph remains intact and running. Then, when the device
becomes available again, allow the user to reconnect
to it (this must NOT be automatic). This is to minimise
'down time' when someone accidentally pulls a cable
during a concert or recording (a classical orchestra
is orders of magnitude more expensive than an anechoic
room).

Ciao,

-- 
FA