[LAD] pipewire

[Wim Taymans]

On Thu, 20 Jan 2022 at 12:16, Fons Adriaensen <fons at linuxaudio.org> wrote:
>
> 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...)
>

I'll probably make a release next week.

>
> > 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...
>
I've added an option to disable the channelmixer and volume updates to it now.

I've also added an option to automatically configure the device with
the max amount of channels probed from the device.

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

It depends on the channel layout, first channels that match will be
copied, then there are some simple heuristics to make channels out of
the other ones (front center from stereo, copy front to rear channels)
or mixing channels into other ones (rear channels into stereo). This
is nothing fancy but good enough for default consumer use.

> > 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.
>
I agree, I'm adding options to disable the extra automatic
things by default.

>
> 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).

Very doable with a little lua script in wireplumber..

>
> Ciao,
>
> --
> FA
>
>
>
>
>
>
>
>
>