To view parent comment, click here.
To read all comments associated with this story, please click here.
_txf_,
Thank you for the link, definately informative. However it seems to contradict Lennart's recent statements in a few places. Particularly:
"We become much less dependant on what the sound hardware provides us with. We can configure wakeup times that are independant from the fragment settings that the hardware actually supports."
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. Pulse audio can therefor update the DMA buffer at any time without synching with the sound card timer.
This is great (no sarcasm), but I don't get why he claims a break in compatibility was necessary. What technical reason is there that pulse audio could not revert to sound card IRQs instead of breaking things? In the absolute worst case, this would have resulted in higher latency, which is at most a minor annoyance.
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?
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).
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.





Member since:
2008-03-17
Ah, but is that because Pulse is so much better than everything else (OSSv3, OSSv4, FreeBSD OSS, OpenBSD sound, etc)? Or just because ALSA sucks so horribly?
The fact that projects use Pulse over raw ALSA just shows how bad raw ALSA is; it has no reflection whatsoever on any other audio stacks.
With the exception of Bluetooth audio, everything you can do with Pulse, I can do on FreeBSD using "that poor pathetic OSSv3", including all the different mixing of channels, redirecting of the network, multiple soundcards, multiple sources, etc.
Oss does not do high latency audio or timer based audio. So every sound is data transfer operation happens synchronously. So if you have a 10 min audio stream the bus stays active for the entire 10 minutes. With pulse it is upload chunk, then sleep some time then upload another etc...
see this, it explains it far better and more completely:
http://0pointer.de/blog/projects/pulse-glitch-free.html
Edited 2011-07-07 21:43 UTC