See also How does PulseAudio start?.
When the PulseAudio audio daemon starts, it by default loads module-udev-detect
, which detects and opens all of my sound cards. PulseAudio uses ALSA to interface to the hardware; ALSA is a combination of kernel moadules and userspace libraries.
As a result of PulseAudio opening all the sound cards, and as a result of the fact that ALSA cards can only be opened once, I get a "Device or resource busy" error when I try to open an ALSA card after PulseAudio has started:
$ arecord -D hw:2 -f S16_LE -c 1 -r 48000 -d 3 t.wav
arecord: main:830: audio open error: Device or resource busy
I am wondering about this design decision. Why is it necessary for PulseAudio to open all devices when it starts?
As a user, I would rather have PulseAudio only open what it needs, when it needs it. If there is a problem opening that device, then I would want the error to be reported back to the client application - the one that tried to read from or write to the PulseAudio device.
The advantages of on-demand device opening:
ALSA and PulseAudio can coexist. I don't have to quit the PulseAudio server to start an ALSA application.
I can know if someone is spying on me. If a microphone device is open when I'm not using it, then that would be suspicious; with the current design it is normal.
Device-related errors can be reported directly to the user, as with ALSA, rather than to a logging facility.
I could run two versions of PulseAudio on the same system, and I could decide at runtime which server should control which devices.
I could, with little effort, run PulseAudio side-by-side with another (better?) sound server.
What are the disadvantages? Is there some technical issue that I'm not aware of, that prevents a Linux sound server from releasing the devices it knows about, when it is not using them? Did earlier sound servers like the ESD also adopt this mode of operation? Is the decision to preemptively open all devices anti-competitive, i.e. is it intentionally making it harder for other sound servers to compete on the Linux platform?
/proc/asound/*/hw_params
- why not do this? And how is it not creepy to have my microphone always open? I understand the basic principles you're invoking, just don't see how it adds up to a good design.. – Metamorphic Dec 29 '20 at 22:27