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 480010
To read all comments associated with this story, please click here.
Broken audio hardware
by Alfman on Thu 7th Jul 2011 18:00 UTC
Alfman
Member since:
2011-01-28

Granted I don't know the details, but if the drivers and hardware work under other operating systems and earlier linux distros, then one has to ask why pulse audio broke things.

I've seen many problems go away when pulse audio was uninstalled. From a user perspective, and even as a dev, my instinct is to say pulseaudio was at fault. Maybe they are feature limited in some way, but it bothers me greatly to use that as an excuse for breaking audio under many linux distros.

Reply Score: 3

RE: Broken audio hardware
by diegocg on Thu 7th Jul 2011 20:17 in reply to "Broken audio hardware"
diegocg Member since:
2005-07-08

Pulseaudio uses code paths that implement advanced functionality; these code paths had never been tested in many drivers because most people didn't use them and nobody cared about it. Pulseaudio forced maintainers to implement correctly all the advanced stuff. If Linux had more people working on the audio stack maybe those bugs could have been fixed sooner, but we don't have that luxury.

The criticism to Pulseaudio is getting ridiculous. Nobody knows the name of the people that actually had bugs in their drivers, but everybody hates Lennart for exposing them? What is next, should we hate the ACID tests because they expose bugs in IE?

Edited 2011-07-07 20:18 UTC

Reply Parent Score: 10

RE[2]: Broken audio hardware
by phoenix on Thu 7th Jul 2011 20:46 in reply to "RE: Broken audio hardware"
phoenix Member since:
2005-07-11

Ah, the hypocrisy. ;)

People defending PusleAudio because it "exposed bugs in the drivers" and was sorely needed to advance the Linux audio stack, yet lambasting KDE4 for doing the same to the graphics stack.

(Not saying you are doing that.)

Reply Parent Score: 7

RE[2]: Broken audio hardware
by cmchittom on Thu 7th Jul 2011 20:59 in reply to "RE: Broken audio hardware"
cmchittom Member since:
2011-03-18

The criticism to Pulseaudio is getting ridiculous. Nobody knows the name of the people that actually had bugs in their drivers, but everybody hates Lennart for exposing them? What is next, should we hate the ACID tests because they expose bugs in IE?


Anybody that hates Poettering for that needs to have his head examined. It ain't that serious.

I do think the interview showed a good deal of arrogance on Poettering's part, for example when he says (when asked about the BSDs continuing to use OSS instead of ALSA or PA:

[OSS] doesn't really have any relevance for what you need for a modern desktop.


He doesn't explain it except to say

You cannot implement logic like timer-based scheduling on it (whih [sic] is mandatory to properly handle more than one client with different latency constraints or latency at all, and all that in a power consumption friendly way), and doing mixing and sample conversion in the kernel is pretty questionnable [sic] too.


Never mind that I use OpenBSD as my desktop and my only real audio need is to listen to my music, which I do quite easily. Never mind that I never need to "handle more than one client with different latency constraints" and that I've never done mixing or sample conversion. Never mind that it's a very very small subset of the people who use Linux who need to do those things anyway.

I'm not annoyed at him exposing bugs or implementing what could well be a better way overall. On the contrary, those are good things. I'm annoyed at his insistence that something which fills all my needs (even if it doesn't fill absolutely everyone's) is wrong and must be replaced by a much buggier stack that is—in execution if not design—less functional.

Reply Parent Score: 1

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

diegocg,

"The criticism to Pulseaudio is getting ridiculous."

It's apparent from the voting that your opinion is more popular here, but I really don't think it's ridiculous to criticize pulseaudio (and the distros loading it) when the result was many broken systems.

Personally I am obviously still a devoted Linux user, but these things should not happen with a professional OS. Even if the changes were ultimately beneficial, the chaotic process through which pulse audio was released is unfortunately a set back to the credibility of a reliable OS. It is exactly this sort of mismanagement that fuels the cry that linux is not ready for the desktop.

Reply Parent Score: 4

RE[2]: Broken audio hardware
by Yamin on Sat 9th Jul 2011 02:28 in reply to "RE: Broken audio hardware"
Yamin Member since:
2006-01-10

You shouldn't hate the ACID tests...

but imagine if the Google made their homepage make use of advanced HTML features requiring 100% ACID pass rate. Suddenly 90% of the world can't access Google when they previously could?

That would create a huge storm as well.

At the end of the day you make your products for your users. Google would never do that to it's users.

Neither should Linux distros.
The fault lies with the distros for packaging pulse audio when a lot of audio drivers didn't implements advanced functionality 100%.

Reply Parent Score: 3