Linux Ubuntu 20.04.3 What audio option has better performance quality ? ALSA, PulseAudio, openal or OSS ? What is the bettter overall sound option ?
Thanks for reply.
Easy answer: ALSA is the best option. The other APIs just run on top of ALSA, and PulseAudio is particularly horrible, another stupid Pottering effort towards screwing GNU/Linux.
Use ALSA, don’t even think about it. Less overhead, less audio lag, less dependencies, more fun.
facepalm 
ALSA is routed through PulseAudio on any modern Linux distro out there. So you might as well select the PulseAudio driver instead to talk directly to PulseAudio rather than go through PulseAudio’s ALSA wrapper plugin.
In other words, if you use the PulseAudio driver, RetroArch sends audio directly to PulseAudio. If you select the ALSA driver, RetroArch sends audio to what it thinks is ALSA, but it’s not, it’s PulseAudio’s ALSA wrapper plugin. That wrapper than forwards the audio to PulseAudio. So there’s an extra unneeded step. Which in turn means you’re making things worse, not better.
If you’re on a PulseAudio system (which is virtually the case on every Linux distro out there), then the best choice is PulseAudio. You’re on Ubuntu, which uses PulseAudio, so that’s the RetroArch driver you should use.
All of these other drivers are there for systems that don’t use PulseAudio. Ubuntu uses PulseAudio, so there is no reason to select anything else.
Thanks. Have a nice day.
That makes literally no sense. Anything audio on a Linux system, and I mean ANYTHING, goes thru ALSA. Read for 5 minutes, please:
https://linuxhint.com/guide_linux_audio
Stop spreading missinformation, please. ALSA is the low-level audio API on ANY GNU/Linux system. PulseAudio runs on top of it. In fact, as I said, ANYTHING runs on top of it.
For low latency, use ALSA. PulseAudio is NOT intended for low-latency audio, it’s a high-level audio server.
What really, really worries me is that people who can’t tell between ALSA al PulseAudio go and decide to ditch ALSA support in the future with some “ALSA is old, lol, lmao!” without thinking how important low-level API access is in LibRetro / RetroArch.
@aug Do yourself a favor and use ALSA for low-level audio, which is what you need for low-latency as intended in emulation.
When an application uses ALSA on a system that runs PA, what happens is that alsa-lib’s PA backend is used. The “default” ALSA device is mapped to the “pulse” device, which is provided by alsa-lib’s alsa-plugins package. See:
https://github.com/alsa-project/alsa-plugins/blob/master/doc/README-pulse
and:
So when an application uses ALSA, you get audio routed like this:
Application -> ALSA PA backend -> PA -> ALSA.
When the application uses PA, you get:
Application -> PA -> ALSA.
So by telling an application to use ALSA, you introduce an unneeded step. Instead of talking directly to PA, you instead talk to the ALSA PA backend first, which then sends the audio to PA.
If your system does not run PulseAudio at all, then yes, you should select ALSA instead of PA (otherwise you’d get no audio, duh!). But all Linux distros out there ship with PA by default. You need to do a lot of tweaking to get rid of PA. And there’s no good reason to do that.
Using PA does not mean you get worse latency. In fact, latency is often better compared to ALSA, because PA uses a ring buffer for samples that does not need to be constantly filled. PA is able to add samples into its buffer at an earlier position than ALSA can, which means it takes less time for those samples to become audible.
The only way to get even lower latency than that is to use exclusive access to the audio device with ALSA and with a very low buffer size. But since nobody does that, because this prevents other applications from being able to generate any audio, using PA instead of ALSA is actually a good way to reduce latency.
In my own tests, when comparing PA, ALSA and JACK using the Reaper DAW with VST synths and a MIDI keyboard, PA was able to provide latencies near 5ms. JACK got very close to 2ms. Normal ALSA on the other hand (meaning non-exclussive with dmix) couldn’t handle anything less than 20ms.
I’m not sure where the “PA has audio lag” myth comes from. Maybe it was the case many years ago in early versions of PA. But in my experience, in the last 8-10 years or so (which is when my switch from ALSA to PA happened), PA does not have higher latency than ALSA. Quite the opposite, in fact.
2 Likes
Imho, alsa should only be prefered on embedded/low-end devices where any overhead will matter and no desktop environment is available. In any other case i prefer PA. And yeah, i confirm alsa goes through PA on PA-enabled setups (at least on mine).
Hi,
PulseAudio is a sound server, there’s no kernel-level support for PulseAudio, so anything that sounds on Linux ultimately uses the Linux kernel ALSA support. With my deepest respect to you, questioning this makes no sense.
What happens here is that anything using ALSA on a system with the PulseAudio service, possibly uses an ALSA emulation layer on top of PulseAudio.
So this is the utterly ugly scheme of things:
CASE 1) Program using ALSA (on a system without PulseAudio) -> Direct native kernel ALSA access.
CASE 2) Program using ALSA (on a system running PulseAudio) -> ALSA PulseAudio emulation layer -> PulseAudio native API -> ALSA
Avoid the second case as much as you can.
1 Like
Good thread created. Thanks for all replies.
Just because it doesn’t make any sense to you doesn’t mean it’s not true.
Some linux distributions use ALSA by default. They also tend to not have systemd.
Linux distributions that use ALSA by default.
- Artix Linux
- Void Linux
- GNU Guix System?
I use ALSA on my system because it actually decreases audio latency. I measured it.
If you care about low latency audio, learn how to configure ALSA.
I think it is easier to get reasonably low audio latency with ALSA. Configuring audio latency with pulseaudio is more difficult because it has many high-level concepts that interfere with low-level concepts. With ALSA, you only need worry about dmix.
I think I may try pipewire.
Yep. But what I’m saying is that when a user of a “high-profile” distro like Ubuntu asks what driver to use, the answer is PulseAudio. Anything else doesn’t make any sense.
And this is a self-correcting problem. A user of a Linux distro that doesn’t use PA already knows the answer to the question 
No, it does not make any sense because kernel-level audio support is ALSA, not PulseAudio which is a sound server with an ALSA emulation layer. Period.
What are you trying to do here exactly? What do you get by adding so much intentional confusion?
I suggest you read the thread from the start again, slowly. Then you’ll see an Ubuntu user asks what audio driver to use, and the answer to that question is PulseAudio. Not ALSA.
It seems to me you were simply mistaken about what happens when you use the ALSA driver on a PulseAudio system. You thought it’s somehow better, which it isn’t. Now you’re trying to create some kind of argument, but it isn’t clear what that argument is exactly.
The situation is very clear. If your Linux system uses PulseAudio (which is the case with Ubuntu,) use the PulseAudio driver. If your Linux system does not use PulseAudio, use the ALSA driver.
I’ll close since this is apparently a heated subject.
Summary for anyone who wants the answer :
- if you have pulseaudio installed, you should use pulseaudio as audio driver (alsa is only “emulated” - for compatibility with software that aren’t “pulseaudio ready” - on pulseaudio setups, so there is no point choosing it)
- otherwise, use alsa (you don’t really have the choice anyway)
As for the pros & cons of installing pulseaudio :
- it has more overhead than using directly alsa
- some people are saying it has less audio latency, some people are strongly disagreeing, so i guess you’ll have to test and make your own mind if you care about this
- mixing different applications towards different outputs is way easier when using pulseaudio, personally i care a lot about this but i guess that’s kind of a niche usage
2 Likes