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 480109
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[7]: Broken audio hardware
by _txf_ on Fri 8th Jul 2011 09:25 UTC in reply to "RE[6]: Broken audio hardware"
_txf_
Member since:
2008-03-17


From your link, the main difference from traditional audio processing is that "pulse audio glitch-free" opts not to use sound card timers/IRQs and use system timers/IRQs instead to provide even lower latency than is available through the sound card.


From my understanding the goal here is generally the opposite (to allow application that are not affected by latency to provide sound output at the highest latency possible yet have the flexibility for low latency).

I'm not understanding the technical reason that pulse audio couldn't revert to using sound card IRQs as they were intended instead of breaking sound support all together? Can someone clear this up?


The thing is that using the sound card irqs would result in generating an interrupt for every fragment of sound that is sent to the soundcard.

The fragment size is fixed by the soundcard and not the system, hence not dynamically reconfigurable. Also note that the soundcard has no information on the system and as such cannot make any judgements on the best solutions.

Reply Parent Score: 4

RE[8]: Broken audio hardware
by Alfman on Fri 8th Jul 2011 20:05 in reply to "RE[7]: Broken audio hardware"
Alfman Member since:
2011-01-28

_txf,

"From my understanding the goal here is generally the opposite (to allow application that are not affected by latency to provide sound output at the highest latency possible yet have the flexibility for low latency)."

Yes I understand that.

"The thing is that using the sound card irqs would result in generating an interrupt for every fragment of sound that is sent to the soundcard."

Yes, but so what? He says himself this IRQ interval is adjustable. Besides, isn't it a little silly to claim that cutting out the sound card IRQs is beneficial when you end up resorting to increasing the system irqs by an order of magnitude? (He admits this in the link).


"The fragment size is fixed by the soundcard and not the system, hence not dynamically reconfigurable. Also note that the soundcard has no information on the system and as such cannot make any judgements on the best solutions."

It was a very long time ago, but I did some sound card programming in Dos/W98 days and I can say that sound cards would accept any DMA size you programmed them with. I'm not sure about the fragment size, but I always just used two.

The two objections which Lennart has with this (working) model seems to be latency and audible clicks when changing sound card parameters dynamically. This is totally plausible. However, these are minor quibbles for most users who just want the audio to work. Pro users who want better audio can always buy a better sound card.

I totally "get" the benefits of switching to a zero-latency model. To be sure, it is worth having. But why was pulseaudio built with all or nothing support? Where is the technical reason pulse audio could not have been programmed to optionally run off of sound card IRQs at the expense of latency?

There would have been no negative for existing users who were already content with their audio latency/power consumption/IRQ rate/etc.

Reply Parent Score: 2

RE[9]: Broken audio hardware
by _txf_ on Fri 8th Jul 2011 21:03 in reply to "RE[8]: Broken audio hardware"
_txf_ Member since:
2008-03-17

Where is the technical reason pulse audio could not have been programmed to optionally run off of sound card IRQs at the expense of latency?


Probably no real reason other than the authors vision and the lack of desire to add complexity to the code. Of course other kinds of complexity have been added (like network transparency etc) so I don't know how valid the second point is.

I also suspect that because pulse is meant to be "the" single userspace api (outside of jack for pro audio) they didn't want its functionality to diverge from the primary form. Also If people wanted that they could just stick with alsa and dmix...

Reply Parent Score: 2