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?

1 Answer 1


The general design of a sound server is to accept data from a wide variety of software and route it to a useful audio device, and vice versa (for input).

Since that's the goal, PulseAudio needs to know about the capabilities of each device it wants to use. It must therefore open them to query capabilities about things like supported sample sizes and expected latency, as well as device names (because the user will want to know that to select the device). Once it's done that, it can present those options to the user.

If the user wants to play something to a device, PulseAudio can just play to that card if the card is already open. If the card is not open, then PulseAudio must first acquire it, which may not work if another device is using it. In that case, the user will perceive their sound to be broken without a justified reason. Similarly, the user may question why their microphone doesn't seem to be producing sound.

Because the average user does not know about or want to look at logs, having suddenly broken sound which required inspecting logs, especially if trying to start something like a video meeting, would be at best irritating and at worst an insurmountable problem. I'm a highly technical user with decades of experience on Linux and I don't want to troubleshoot sound problems (or any problems, for that matter).

Acquiring all the sound cards and then having ALSA use PulseAudio as the default ALSA device means that programs which know how to use ALSA but not PulseAudio will just work without contending with other programs. Otherwise, for example, your audio player could hold onto the card while preventing sound effects like your terminal bell from working. This is not an uncommon problem, in fact; it's why PulseAudio is supported as an ALSA output device.

Of course, this design doesn't meet everyone's needs, but it does produce the simplest, most robust behavior, since cards which are displayed to the user are generally usable, and those which are not are not. It may be possible to produce the behavior you desire with some configuration, or you may prefer to use a different solution, such as JACK or ALSA with dmix.

  • Thank you. "having suddenly broken sound which required inspecting logs" - I was suggesting that the error would be reported to the client, and thence to the user. The current design requires inspecting logs, since a device failure is encountered long before anyone tries to open it. In my proposal, errors would appear on standard error. Also, why do you say that PulseAudio needs to know about the capabilities of a device before someone opens it? I thought it did rate conversion and so on transparently. Dec 29, 2020 at 0:01
  • That assumes a consistent way to usefully report errors to a graphical client and robust handling of this case, which is unlikely. Errors are typically handled poorly and the average user won't know what to do to fix the problem. You also need to know information about the device so it can be displayed to the user (is it stereo? mono? 4-channel?) and so you can mix data properly. No point using a fancy 24-bit algorithm for an 8-bit channel.
    – bk2204
    Dec 29, 2020 at 0:18
  • I'm not persuaded, sorry. All of the GUI applications I use have ways to report simple errors like "Device or resource busy". What are you saying is better in the current design? Can you give an example where PulseAudio preemptive device opening saves users from looking in log files? Also, if you just need the hardware parameters, you could get it from opening and closing the device, or from /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.. Dec 29, 2020 at 22:27
  • Well, you asked for an explanation. I provided one. It may not be a compelling argument for you, but it is a reasonable set of design choices given the circumstances. If you want something more authoritative, you'll have to ask upstream.
    – bk2204
    Dec 29, 2020 at 23:44
  • Fair enough. You put forth good points, and thank you for contributing them. Dec 31, 2020 at 2:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.