20 Jan
2022
20 Jan
'22
9:11 p.m.
On Thu, 20 Jan 2022 at 12:16, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
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.
I agree, I'm adding options to disable the extra automatic
things by default.
Hello, Wim,
I'll probably make a release next week.
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 ?
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.
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