Apps using both alsa and pulseaudio, headless and multi-user desktop

We have a PC running Manjaro which has two intended roles:

  • A general purpose desktop that everyone in my family uses for a variety of purposes (mostly media and games)
  • As a headless music server running both MPD and spotifyd

The desktop application needs to use pulseaudio for sound, since increasingly many apps only support that (e.g. Firefox).

The music server daemons (MPD and spotifyd) start at boot time, and run as their own application-specific user (i.e. not root, but also not associated with any human user).

If MPD or spotifyd are configured to use ALSA, then whichever one starts first gets exclusive control of the audio device, and sound doesn’t work for the other daemon, nor desktop apps. If those apps are configured to use pulseaudio with TCP streaming, then they only work when someone is logged in.

One solution is to use Pulseaudio in system-wide mode[/url], but this is not recommended (and not an officially supported configuration).

So I’m trying to figure out what the “right” way to do this is. Based on my understanding (could be wrong!), I think there are two possible solutions:

  • Have the application-specific accounts for MPD and spotifyd be able to launch their own instance of pulseaudio when they need the audio device (i.e. mimic what would happen when a human user logs in), or
  • Have the MPD and spotifyd daemons “share” ALSA with pulseaudio. I think the way to do this is to configure ALSA’s “dmix” facility (i.e. the main way multiple ALSA apps shared the audio device). But I’m not exactly sure how to do this (I struggle with ALSA’s config syntax).

Any Linux sound config experts out there who can help?

Thanks!

Why do you think this? Pulseaudio can be run as a deamon but it’s overkill if you just have one user at the computer, but makes perfect sense in your particular use case, so why not?

:thinking:

OK. Even going with the system instance of PulseAudio, I still have a related problem: ALSA-only apps runing alongside PulseAudio. There appears to me two ways to have native ALSA apps and PulseAudio share the actual sound device:

  • Have ALSA actually be a pass-through to PulseAudio, or
  • Use dmix so that all apps (including PulseAudio) can share the hardware at the ALSA level

Both ways are covered in the Arch Wiki on PulseAudio. (I’d link it, but I’m not allowed to post links.)

The first way is implicitly recommended, since for the second way it’s flagged as an “alternative configuration, which is generally not recommended.” I’m curious as to why it’s generally not recommended?

The latter way seems more intuitive to me. If your application is ALSA native, and does not support PulseAudio, they why have PulseAudio be involved at all? ALSA’s dmix is capable of multiplexing streams. In the first method, the data flow looks like this: application -> ALSA -> PulseAudio -> ALSA -> hardware. It seems like there is an extra step?

Thanks again!