How to configure PulseAudio to input/output via ALSA?

Question

How do I configure PulseAudio to use only a single ALSA device for input and output?

The default PulseAudio configuration causes PulseAudio to open all ALSA devices when it starts. This makes it impossible to use PulseAudio together with other ALSA clients. Many people prefer PulseAudio to ALSA, but other users find it frustrating. For better or worse, PulseAudio has become a standard and several popular Linux applications, such as Skype and Firefox, only support audio output via PulseAudio.

Some users prefer to work with audio clients that output directly to ALSA, others output to another audio framework like JACK, but want to have JACK access ALSA directly. For these users, it is easy to free up all the ALSA devices by uninstalling PulseAudio. However, removing PulseAudio makes it impossible to use audio in Skype and Firefox.

A better solution would be to come up with a configuration that gets PulseAudio to "play nicely" with other ALSA clients, outputting to only a single device, which would be specified in its configuration, or even just the ALSA default device. How can we do that?

Solution 1

This answer builds on @dirkt's answer, so thanks are due to him.

1. You can edit ~/.config/pulse/default.pa. It's listed under FILES in the "pulseaudio(1)" manual page. If it is present, the global default.pa is not used. For me, I can get a working setup with the following minimal configuration:

   load-module module-alsa-sink device=default
   load-module module-alsa-source device=default
   
   load-module module-native-protocol-unix
   

   However, you may want to look at the global version, which is /etc/pulse/default.pa on my system, to see what else could go in this file. There are all sorts of bells and whistles configured here: modules to restore volume settings, discover bluetooth devices, interface with JACK, automatically quit the daemon when user logs out, and so on. If you decide to copy the global file to your home directory and edit it, or even to edit the global file directly, you'll need to do the following:

   • Comment out load-module module-udev-detect, which searches for ALSA hardware devices and overrides the device argument you passed to the ALSA modules above.
   • Then add the module-alsa-sink and module-alsa-source lines. The module-native-protocol-unix line should already be present.
   • You may need to comment out the line load-module module-suspend-on-idle; this caused problems for me in testing with certain output devices. The symptom is that mplayer -ao pulse ... reports "Audio device got stuck!" and mpv -ao pulse ... reports "[ao/pulse] The stream is suspended. Bailing out." Commenting out that module fixed the problem.

2. If you choose different devices than device=default above, for example two separate ALSA devices for record and playback, then it won't work in my experience - parecord tries to record from the sink device rather than the source device. If you have configured separate devices for input and output via ALSA, and you want them to be named by the same PCM device, you need to put something like this in ~/.asoundrc:

   pcm.!default {     # "!" means "override" the previous definition
       type asym
       playback.pcm "hw4mix"
       capture.pcm "hw:5"
   }
   

   Here hw4mix names a dmix device defined previously in the file; while hw:5 specifies the hardware device for my USB microphone. This makes PulseAudio happy. If you wanted to use a special device for PulseAudio clients, you can name it "special_pulseaudio_device" instead of "default" (and of course update default.pa to refer to it).

3. Test. Use pulseaudio -k or killall pulseaudio to kill the current PulseAudio daemon. Then start it again with pulseaudio -vv. Of course, you'll need to do this every time you edit ~/.asoundrc. Once you have a working setup you could try something like pactl exit; pulseaudio --start. The --start option makes it run in the background, where you won't be able to see error messages.

   Use parecord -v t.wav and paplay -v t.wav to record and play a WAV file. You should be able to have these commands running at the same time.

   • Since I use a dmix device for playback, I can use paplay and aplay together, and mixing occurs automatically. However, the microphone can't be shared in my setup; I cannot record from it using arecord when PulseAudio is running ("Device or resource busy"). For that I would need to create a dsnoop device and put its name in place of hw:5 above.

   • If you're trying to get Skype to work, use the Skype "Echo / Sound Test Service" to test your setup. Keep in mind that Skype may be already be running in the background - try killall skype before starting it, to force it to make a new PulseAudio connection. In my experience, Skype does not report any kind of error condition when it is not able to connect to the PulseAudio daemon.

Having a good ALSA configuration is desirable, even if only because certain applications (Ecasound? legacy code?) don't work with PulseAudio. I hope that these instructions are helpful to anyone who, having configured ALSA to their liking, now wants to be able to use programs like Skype which depend on PulseAudio.

Solution 2

You don't configure PulseAudio to use the ALSA default device. Instead, you configure ALSA to use pulse as the default device:

pcm.!default pulse
ctl.!default pulse

In that way, ALSA applications that are not aware of PulseAudio will use PulseAudio via that indirection layer.

The reason you need to do this is that PulseAudio always uses ALSA as backend, and on startup opens all ALSA devices, and since most ALSA devices can't be opened multiple times, this will cause all ALSA applications that try to use an ALSA device directly when PulseAudio is running to fail.

If you have a legacy application that for some reason doesn't work, you can use pasuspender to temporary suspend PulseAudio to run this particular application.

I was actually in a similar situation like you are now, I used ALSA for a long time, and was happy, and was then forced to switch to PulseAudio. PulseAudio has in principle a nicer, more general structure than ALSA (streams and sources/sinks), and though sometimes it has warts, one can live with it.

You can debug problems by starting pulseaudio manually and adding -v flags, like pulseaudio -vv start etc. Log messages go to the syslog. If you want to switch devices, pavucontrol is an easy-to-use GUI, and if you want more direct control, you can use pacmd or pactl (I never figured out why there are two programs) as a commandline CLI. Use the help argument for more details. If you prefer files, everything easily scriptable.

I also recommend to have a look at the available modules.

Comments

[Metamorphic]

Thanks for the explanation, that was quite helpful (even new to me was "PulseAudio always uses ALSA as backend, and on startup opens all ALSA devices"). I accepted your answer, but looking at the list of PA modules you linked, I see there is a "module-alsa-sink" and a "module-alsa-source", so it seems that the configuration I'm looking for should be possible. If someone else also wants to describe how to do this, I will be grateful.

[dirkt]

As the comment there says: "You should (almost) never need to load this module manually. Let module-udev-detect look for the supported cards and then select the profile you want, that will make the right sinks show up.". Pulseaudio is superior to ALSA in letting multiple application uses the same sinks and sources, while providing volume control on top of that. If you disable module-udev-detect, and make module-alsa-sink use a dmix sink (assuming that works), you won't be able to do that properly. Just give the default way a try.

[Metamorphic]

I've been "giving it a try" off and on for 10 years now, and that's too long. I don't need a GUI, I don't need a daemon, and I didn't even need multiple applications to use my sound card (although as I said in my post, my ALSA config now supports that). pulseaudio -vv doesn't tell me where the problem is, and at this late stage in its development, I suspect it never will. As long as I have alternatives, I'm not going to use a piece of software that refuses to facilitate troubleshooting when something goes wrong. As much as I like coming to Stack Exchange for help :)

[dirkt]

As I said: You don't need a GUI, everything is scriptable with pacmd. I don't even know what kind of problem "sometimes it works, sometimes it doesn't" is, so of course just looking at log messages without trying to understand what goes wrong helps. No software "facilitates troubleshooting"; I never was able to get ALSA to "troubleshoot" my mistakes when I wrote .asoundrc entries. It's really easy to use PulseAudio in the "normal" configuration. It's hard to use PulseAudio in the configuration you want.

[dirkt]

If you want to do it anyway, you need to find out where your distribution puts the PulseAudio configuration and startup files (/etc/pulse/ on Debian), disable module-udev-detect, and pray that module-alsa-sink also works with dmix, and not just with ALSA hardware (because you won't be able to use any other program using ALSA if it doesn't).

[Metamorphic]

Thanks. Now I commented out the udev-detect line and added load-module module-alsa-sink device=hw3mix and load-module module-alsa-source device=hw:5 to /etc/pulse/default.pa (although since hw3mix is defined in ~/.asoundrc, shouldn't I rather be editing a PA config in my home directory?). Now I can use e.g. mpv -ao pulse and hear output on hw3mix (a dmix device). However, when I run arecord -v t.wav I see the line "Connected to device alsa_output.hw3mix.monitor" (as if it is trying to record from the speaker) and t.wav contains all zeroes. So, not yet a solution for Skype...