Quote:
Hi Badley,
It turns off timer-based scheduling for PulseAudio and instead uses interrupt-driven scheduling. Timer-based scheduling should be better in theory, but can cause issues with some Alsa drivers. We believe that audio improves by adding this flag to go back to interrupt-driven scheduling.
Johan.
The basic premise behind PulseAudio's scheduling is that by using high resolution timers PulseAudio can get to the buffer and put up new data before the audio chip is giving the system an emergency warning that the buffer is about to hit the end and needs new data. Some sound cards do this way too late to perform adequate click-free audio, and some sound cards (like streaming PA over a network) simply do not have a timely interrupt for lack of data (complicated by TCP/IP packet loss and so on) and the best way is to simply know when your buffer will last, start playing, and before it gets to the end or gives a late alarm, reschedule some new buffers to play audio.
Unfortunately either the high res timers available to PulseAudio or something to do with the scheduling latency of going into the kernel, modifying buffers and coming back takes far too long. Virtual Machines (in VirtualBox or VMWare workstation) tend to do better with interrupt based scheduling than timer based scheduling as the high resolution timers are emulated as a significantly lower resolution than the host system provides to a natively installed system.
Interrupts are a fact of life; they come through and they are serviced with a given latency and it in general does not matter if they are not handled within a certain period of time (although doing it exceptionally late is usually a problem, systems with 100 interrupt events potentially prioritized generally are built to withstand a little waiting).
Timers are in general not a fact of life. On x86 it is only very recently that they grew a high precision event timer (called the High Precision Event Timer, or HPET, introduced in about 2004/2005) which is required when you're doing fancy things like SMP where the CPU ("rdtsc" timestamp) counters get wildly out of sync, old PIT timer was hard to access (requires an io-mode read), had a limited number of schedulable events (3, but 2 of them are usually used by the system for other things) and in general pretty low resolution.
You can't guarantee that they are there, or even that they are synchronized or particularly real (many high resolution timers in Linux, especially with "tickless" systems, do not actually fire at the time they are ready to fire, only sometime way after when the system has decided it is not a detriment to power management or can batch timer events together).
My personal reading into this is that the timer used on Linux for the MX51 is too low resolution; it's a quit small counter and to stop it from overflowing too often the rate is quite slow, giving it a minimum time between events of somewhere around 3 milliseconds, with the average time to processing it and getting to the rest of the system between 4 and 7 milliseconds. In-kernel msleep(1) actually takes 4 or 5 ms (since it's not possible to count any other way you can't tell what it is, sometimes it's 4, sometimes it's 5, processing overhead included).
The average PulseAudio buffer size is 10ms which means that you will be lucky if you can send the buffer to the audio driver, and receive an event before it is too late to do anything about it.
Another fix for it is to go into /etc/pulse/daemon.conf and increase the default-fragment-size-msec value to 25 or 30 which will give the system much more time at the expense of possibly 15-20ms extra latency playing audio (this is not enough to notice in terms of expediency, but is definitely long enough for the human brain to notice the missing data, but PA does a good job of keeping buffers filled and chained).
Login
Register
FAQ
Search