Alsa-only apps and PulseAudio on same system

matt_garman · 2020-10-30 18:10:57

This is more of a conceptual question as opposed to how to...

I have a situation where I have Alsa-native apps and PulseAudio apps on the same system (with only a single sound output device). I.e., some apps only work with Alsa, others only with PulseAudio.

This is explicitly covered in the wiki. To summarize, it appears there are two ways to do it:

Configure Alsa with a pulse virtual device, making Alsa essentially a pass-through to PulseAudio
Use Alsa's dmix functionality to allow the Alsa-native apps to share the hardware with PulseAudio

However, for the latter approach, the Wiki says, "Note: This section describes alternative configuration, which is generally not recommended."

My question is: why is that not recommended? It seems more intuitive to me. In the first (recommended) solution, the app talks to Alsa, which forwards to PulseAudio, which ultimately forwards right back to Alsa. It looks like an extra step to me. If the app can talk to Alsa, and Alsa has the ability to multiplex streams, why should PulseAudio be involved at all?

Thanks!

Lone_Wolf · 2020-10-31 19:35:51

personally I'd focus on a different method : make pulseaudio apps work without having pulseaudio installed (only libpulse is necessary)

https://wiki.archlinux.org/index.php/Ad … patibility

My question is: why is that not recommended?

I assume you're referring to https://wiki.archlinux.org/index.php/Pu … are_device ?

My gut feeling is that the described method will cause problems, but I can't prove that.
You'll need to wait for someone with more knowledge of audio on linux.

Last edited by Lone_Wolf (2020-10-31 19:36:25)

matt_garman · 2020-10-31 19:57:32

Lone_Wolf wrote:

personally I'd focus on a different method : make pulseaudio apps work without having pulseaudio installed (only libpulse is necessary)

That's an interesting idea for sure, do you happen to have any references discussing that?

I'm actually looking at this question for two different use-cases. In one, I do believe I need the full pulseaudio installation, because I'm using it's network streaming capability.

Lone_Wolf wrote:

I assume you're referring to https://wiki.archlinux.org/index.php/Pu … are_device ?
My gut feeling is that the described method will cause problems, but I can't prove that.
You'll need to wait for someone with more knowledge of audio on linux.

Yes, that's what I was referring to.

To take a stab at answering my own question: I don't know if this is the reason, but: if you route everything through PulseAudio, either directly or via Alsa's "pulse" virtual device, then PulseAudio becomes your single interface for all things sound. In other words, it seems to me, if you have some apps talking directly to Alsa via dmix, and others using Pulse, then it's conceivable you could have different behavior depending on how things are configured. In other words, with the recommended config, you use these tools in their more "pure design intent" sense - ALSA is just for talking to the hardware, and PulseAudio is the "middleman" between applications and the hardware driver (i.e. ALSA).

Not sure if that's the main rationale or not, but I've been playing with such a setup since I posted that. Despite initially thinking I wanted to go the dmix/"not recommended" route, I actually went with the Pulse/recommended route. That means I've spent all my time getting to know PulseAudio in more detail, but I've spent virtually zero time messing with ALSA. And I feel like, had I gone with the dmix config, then I would have spent all the time I already spent on Pulse, and that much more monkeying with Alsa.

V1del · 2020-11-01 11:52:23

Your stab at answering your own question is more or less the gist of it.

The actual question at the end of it is who should be the final entity to pass audio to the kernel driver. The answer here is either dmix or pulseaudio, the audio card can only be accessed by one thing at a time. Dmix is less flexible here, it is one hard coded piece of configuration and whatever you are doing is under those limitations, pulseaudio as an actively running daemon can readjust how it handles the card based on the needs of the audio clients currently connected to it. It can lower sampling requirements, increase and decrease latencies depending on who's requesting what.

The dmix approach has it's benefits in so far that everyone is treated equally. If there's a delay, everyone will be delayed if you have mismatching sample rates everything will be resampled to 48000 regardless of who's playing when. Pulseaudio's flexibility tries to ensure that every client gets it's best possible configuration as possible at any given time, the drawback here is that sometimes a incorrectly configured client could run into issues with the information given to it by pulse.

If you were to go with the "pulse as a dmix device", you'd throw that out of the window, as now pulse has no control over the audio device anymore and all is left to the single configuration of dmix. Which is in my opinion the worst of both worlds. So if you are happy with your pulse setup and it works with what you are trying to do and you didn't notice any hiccups with the ALSA clients I'd suggest you stick to the current approach.

Also, if you rely on the network capabilities of pulseaudio actual ALSA clients would not be able to make use of these with the "dmix" approach.

Last edited by V1del (2020-11-02 08:40:12)

Arch Linux

#1 2020-10-30 18:10:57

Alsa-only apps and PulseAudio on same system

#2 2020-10-31 19:35:51

Re: Alsa-only apps and PulseAudio on same system

#3 2020-10-31 19:57:32

Re: Alsa-only apps and PulseAudio on same system

#4 2020-11-01 11:52:23

Re: Alsa-only apps and PulseAudio on same system

Board footer