Skip to content
Advertisement

ALSA vs PulseAudio – Latency Concerns

Good day,

I have been debating some details with a colleague about ALSA vs PulseAudio, and need some help coming to a conclusion with it. It’s to my understanding that ALSA is relatively low-level, and talks directly to the hardware, while PulseAudio sits on top of ALSA as a service.

Additionally, it’s to my understanding that ALSA is tied to Linux, but PulseAudio just acts as an abstraction layer on top of ALSA, and can work on other platforms. My conclusion is that ALSA would provide lower audio latency on most Linux systems, while my colleague contends that PulseAudio provides better (shorter) latency regardless.

Which of us is correct? My reasoning is that since PulseAudio sits on top of ALSA or even wraps it, there’s no way it could provide better latency unless it’s providing its own low-level calls.

Thank you.

Advertisement

Answer

ALSA (like many other sound APIs) provides a ring buffer for samples to be played.

The most common way to use this ring buffer is to keep it filled at all times. This implies that a sample that is written now is played only after all the other samples in the buffer have been played, i.e., the latency is proportional to the buffer’s size. (The buffer size can be chosen by the application, but depends on the capabilities of the hardware, and is fixed once chosen.)

PulseAudio has the ability to keep only a part of the buffer filled. (This is not a feature offered directly by ALSA, but requires a separate timer to monitor the playback progress.) Thus it can offer lower latency than other applications using the same buffer size, but more importantly, this allows it to adjust the latency dynamically without having to stop and reconfigure the device.

Other applications could do the same, but it’s easier to use PulseAudio than to implement that buffer handling again.

User contributions licensed under: CC BY-SA
3 People found this is helpful
Advertisement