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?
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?
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?
I’m curious as to why it’s generally not recommended?
I agree - It does not explain why it is not recommended or have a url to explain further
Another part of Archwiki suggests using dmix with PulseAudio
PulseAudio as a minimal unintrusive dumb pipe to ALSA - PulseAudio/Examples - ArchWiki
And the ALSA section has information about dmix with no similar warnings
Dmix - Advanced Linux Sound Architecture - ArchWiki
The only comment I know of relating to ALSA audio quality is at the end of this wiki page
the complaint there was about CD audio 44100Hz resampled to 48000Hz, because dmix has to be set to a fixed sample rate
there might also be issues with high latency if the buffer size is too large, or glitches in audio if the buffer is too small
I do not know of anyone that has used dmix in the last few years since PulseAudio became better behaved (even Slackware has finally accepted PulseAudio)
But even in ALSA documentation that is older than PulseAudio it was recommended to use a sound server software before considering dmix
Sharing a device - Linux ALSA sound notes
(Polypaudio was created to replace EsounD and was later renamed to PulseAudio)
Thank you for your thoughts and input. Thinking about this some more, my take is as follows: when using Alsa as a passthrough to Pulse, Alsa is essentially used in the “pure” sense, i.e. as an interface to the hardware; likewise, Pulse becomes the one single interface between Alsa and applications. Whereas, if you use dmix, then you have both Alsa and Pulse doing similar things (multiplexing and/or resampling audio), so you could in theory have inconsistency between apps using Alsa directly and apps using Pulse.
I also posted the same question on the Arch forums. I can’t post links, it’s under the “Multimedia and Games” section, title “Alsa-only apps and PulseAudio on same system”.