On Monday, 4 July 2022 16:47:46 CEST Fons Adriaensen wrote:
On Mon, Jul 04, 2022 at 04:29:13PM +0200, Iyán Méndez Veiga wrote: As far as I'm aware, Pipewire sits on top of ALSA. So in your case I'd expect just ALSA to work as well. Maybe you could test...
What do you want me to try?
I'm not an expert and I never looked into too much detail about this. Pipewire simply works for me.
For example, running `arecord [...] doesn't work but selecting pipewire [...] does the trick [...]
Hi, only one client can grab an ALSA input or output device. Take, for example, the case of a browser playing a video or as in your case a sound server does already access the device, then neither a music player or by command line something else can use the same ALSA device, too. Before arecord can access the ALSA device, pipewire must be disconnected from it. As soon as pipewire released the audio device, test with arecord again. In a nutshell, only a single client can access an ALSA device, such as a sound card's input or output channel directly. Several clients can access a sound server. The sound server shares the hardware inputs and outputs with the inputs and outputs of clients. When using plain ALSA, without a sound server or without https://alsa.opensrc.org/Dmix only one client at a time can use an audio hardware input or output channel. I'm using either plain ALSA (without dmix) or the jack sound server, but not a ThinkPad's audio device, hence I can't help with this. However, since pipewire seemingly doesn't replace the ALSA drivers, usage of the ThinkPad's audio input and output channels should work with plain ALSA, too. IOW if ALSA already fails, then pipewire unlikely does fix this issue, unless pipewire does fix bad ALSA configurations automagically. Maybe pipewire does (re)configure ALSA, but way more likely is, the more layers, the more issues. Regards, Ralf