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 480038
To read all comments associated with this story, please click here.
RE[2]: Also, why?
by cmchittom on Thu 7th Jul 2011 20:34 UTC in reply to "RE: Also, why?"
Member since:

"In the interview, Lennart says:

[q]An audio stack that is not capable of timer-based scheduling and dynamic latency control based on that is not useful on consumer devices.

Why? I mean, seriously, why? All I want is my computer to play my audio files, and maybe do a nice beep at me when it pops up an error dialogue.

Well, yes and no. In the short term you've got a point; and in the longer view there is a point where it has to be engineered right to be capable across a range of applications. [/q]

Again: why? Or put better, why are these mutually exclusive? Keep the old way as the default, but offer the new way as an option until the kinks get worked out—lots of distributions used this strategy for the ext2–ext3 transition, I seem to recall.

Frankly whenever and whoever took the bull by the horns saying, in effect: "now is the moment" to sort out the sound sub-system ... would be unpopular for a while.

Sure, I'll buy that. But I think it's beside the point.

He makes the same point himself:
"Also, what other option would there have been? It's pretty naive to believe that if we had waited any longer with pushing PulseAudio into the distributions things would have gone any different: you cannot fix bugs you don't know about, and the incentive and manpower is too small to get them fixed without having the pressure that the stuff is shipped.

Essentially his argument is "We had to push our buggy software on people because, since not enough people are interested in testing it, we have to make them." Does no one else see the enormous problems with that? Not least that if manpower is really that much of a problem for you, maybe you should get the message that it's not something people want or need?

Don't get me wrong, I would have had absolutely no problem if PulseAudio had been optional, or if it had been part of a distribution specifically aimed at people who need its high-end features, even if it had been twice as buggy.

Reply Parent Score: 1