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."
Thread beginning with 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

RE: Timer ?
by _txf_ on Thu 7th Jul 2011 21:17 in reply to "Timer ?"
_txf_ Member since:
2008-03-17

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


All the current (modern) audio stacks do it the same way Pulseaudio does (that is Vista+ and Coreaudio). I do recall many people with old soundcards complaining that sound was busted in Vista (I think it was some of the creative live and audigy cards).

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.


I am so far from an expert that this is probably a worthless point but ...

Soundcards have their own timers (mostly for sampling and audio output). Now, previously audio was done on a buffer basis along the lines of :

Cpu uploads sound output to soundcard buffer, buffer fills and sound is outputted per soundcard clock. It does this synchronously for a determined chunk size of the total sound output. So the bus is active for the entire period. Pulse, however waits for the longest period of time it possibly can and uploads it all in one go. Thus the system can sleep in much longer chunks hence saving power.

Edited 2011-07-07 21:28 UTC

Reply Parent Score: 3

RE[2]: Timer ?
by Neolander on Fri 8th Jul 2011 09:49 in reply to "RE: Timer ?"
Neolander Member since:
2010-03-08

Yep, I probably was tired when I read the sentence the first time, because I read it as "using (broken ?) sound card timer irqs" the first time, whereas now I read it as "using system timer irqs, using timer information provided by the sound card".

I'd like to point out that they could do without the sound card's timer information though, if it was broken, as long as they had sound card IRQ support :
1/Enable sound card IRQ
2/Measure sound care IRQ frequency using ultra high-resolution APIC timer (~.1 MHz audio clock vs an APIC clock that runs at hundreds of MHz = negligible aliasing)
3/Disable sound card IRQ and never enable it again

An ugly measurement is better than unreliable information ;)

Edited 2011-07-08 10:00 UTC

Reply Parent Score: 1

RE: Timer ?
by mutantsushi on Thu 7th Jul 2011 21:25 in reply to "Timer ?"
mutantsushi Member since:
2006-08-18

I can't say I'm actually familiar with the innards of any sound driver, much less PulseAudio specifically,
but I would guess that being able to sync to external MIDI clock may have been a design decider in this aspect.
It also seems like the generically more stable approach... i.e. across CPU architectures including distributed computing, etc.
So the guy thought it was a bad idea to have timing inside the kernel. DOES ANYBODY ACTUALLY DISAGREE WITH THAT?

Perhaps PA didn't match 'generalist' needs at the time, but realistically, 'desktop Linux' with multimedia support wasn't really all that big a market at the time. If it was a big market, the crappy drivers woulnd't have persisted for as long as they have. So surprise, surprise, Linux audio stack developers are interested and focused on functionality useful for audio geeks, e.g. musicians. Is this really out of line for the general trend of Linux development?

Edited 2011-07-07 21:27 UTC

Reply Parent Score: 1