Linked by Thom Holwerda on Thu 7th Jul 2011 17:36 UTC, submitted by vivainio
Linux Linux.FR has an interview with Lennart Poettering of PulseAudio and systemd fame (among others). Regarding PulseAudio: "I can understand why people were upset, but quite frankly we didn't really have another option than to push it into the distributions when we did. While PulseAudio certainly wasn't bug-free when the distributions picked it up the majority of issues were actually not in PulseAudio itself but simply in the audio drivers. PulseAudio's timer-based scheduling requires correct timing information supplied by the audio driver, and back then the drivers weren't really providing that. And that not because the drivers were really broken, but more because the hardware was, and the drivers just lacked the right set of work-arounds, quirks and fixes to compensate for it."
Permalink for comment 480035
To read all comments associated with this story, please click here.
Timer ?
by Neolander on Thu 7th Jul 2011 20:25 UTC
Neolander
Member since:
2010-03-08

PulseAudio's timer-based scheduling requires correct timing information supplied by the audio driver

My guess is that every single former audio architecture dealt with CMOS/PIC/APIC timers and did just fine.

I can't get why PulseAudio would want to mess with soundcard-specific timers while there's tried and true support for several standard x86 timers in the Linux kernel. If there was such a thing as vertical synchronization problems on audio hardware (follow an arbitrary hardware clock rate to do some operations or face artifacts), I could understand, but to the best of my knowledge this is not the case.

Edited 2011-07-07 20:27 UTC

Reply Score: 3