Features/GlitchFreeAudio

Glitch-free Audio

Summary

The PulseAudio sound server has been rewritten to use timer-based audio scheduling instead of the traditional interrupt-driven approach. This is the approach that is taken by other systems such as Apples CoreAudio and the Windows Vista audio subsystem and has a number of advantages, not the least in reduced power consumption, minimization of drop-outs and flexible adjustment of the latency to the needs of the application.

Owner

• Name: Lennart Poettering

Current status

• Targeted release: Fedora 10
• Last updated: 2008-09-09
• Percentage of completion: 100%

The PulseAudio rework is mostly complete, but glitch-free exposes a number of issues in the Alsa drivers: http://pulseaudio.org/wiki/AlsaIssues

Detailed Description

Lennart has written a great explanation of the technical details here .

Benefit to Fedora

Lennarts writeup has a detailed discussion of advantages (and disadvantages) of the glitch-free approach. Some highlights are:

• Fewer wakeups, reduced power consumption
• Dynamic latency adaption
• Less dependent on audio hardware
• Minimized chance of drop outs

Scope

The feature requires a pretty-much rewritten core of PulseAudio.

Test Plan

• Play sound on the desktop in various ways, e.g. music in rhythmbox, or a video in totem, or some flash video in firefox. Verify that the sound experience is the same as on F9.
• While doing the above, run powertop and observe that pulseaudio is not increasing the power consumption as much as it used to.
• Repeat the above with different sound cards

Please note that the power-saving results are usually not as good as you might expect: - For USB hw the wakeup rate is not dependant on the client parameters - The HDA driver artificially limits the maximum size of the playback buffer to 370 ms at 44khz/2ch/16bit. The result of this is that at least one IRQ is triggered every 180 ms or so. Which hence results in already 6 interrupts per second. Which are in addition to a few timer interrupts. You can increase the buffer limit by touching some files in /proc/asound, however since fixing this limitation properly requires some non-trivial changes in alsa's internal memory management we won't be able to use longer buffers by default in F10. In theory however, we should be able to get the number of wakeups to 1 per second during music playback, it's just the underlying infrastructure that's lacking. - Some clients query the latency very often. This will cause them to wakeup and as a result also PA to fulfill their query request. PA now includes some fancy algorithms to interpolate the latency information on the client so that the client can query the server less often. But some clients need to tought about that fact still.

While the power savings are unfortunately not visible on most platforms right now. The drop-out safety and automatic latency adjustment are. On USB this works fine and is visible by simple testing: play music and put load on the CPU and see that PA doesn't start to stutter. (Again, some clients are not really up to this yet, they ask for shorter buffers than necessary and thus artificially increase the wakeup rate).

User Experience

Unfortunately not much of this is directly visible. The location where this is best visible is powertop.

Dependencies

The glitch-free logic will only be enabled on mmap()-capable ALSA devices and where hrtimers are available. The non-glitch-free logic will be preserved as compatibility code with older kernels and limited sound hardware or drivers.

From Lennarts writeup:

• System timers on Unix are not very high precision. On traditional Linux with HZ=100 sleep times for timers are rounded up to multiples of 10ms. Only very recent Linux kernels with hrtimers can provide something better, but only on x86 and x86-64 until now. This makes the whole scheme unusable for low latency setups unless you run the very latest Linux. Also, hrtimers are not (yet) exposed in poll()/select(). It requires major jumping through loops to work around this limitation.

• Generally, this works reliably only on newest ALSA, newest kernel, newest everything. It has pretty steep requirements on software and sometimes even on hardware.

Contingency Plan

If the glitch-free PulseAudio exhibits glitches that cannot be fixed in time for F10, we can just revert to the last 'traditional' PulseAudio release.

To limit the problems with Alsa drivers, there is now a switch "tsched=0" for the module-hal-detect module which will disabled glitch-free mode for all sound cards globally. To use this edit /etc/pulse/default.pa and append "tsched=0" to the line "load-module module-hal-detect"

Documentation

Lennarts detailed explanation is here: http://0pointer.de/blog/projects/pulse-glitch-free.html

Release Notes

The PulseAudio sound server has been rewritten to use timer-based audio scheduling instead of the traditional interrupt-driven approach. Timer-based scheduling may expose issues in some Alsa drivers. To turn timer-based scheduling off, replace the line

load-module module-hal-detect

in /etc/pulse/default.pa by

load-module module-hal-detect tsched=0

---