Re: [LAD] pipewire

Hello, Wim, OK, I'll wait until this is available via Arch (don't want to mix up two potential problems, build/install and configure...) 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 ? 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