> "if the application is not performing its' stated task, to provide audio playback, then it is a bad design."
> ah. So if I can find any system, anywhere in the world, on which audio playback does not work in FreeBSD, you will admit that FreeBSD is 'a bad design'?
> wow, way to paint yourself into a corner, skippy.
Strawman. Plus a thoroughly unjustified strike at petrus4, with the cherry being a thoroughly patronising attitude. Let me be the first to call you on all three of these things.
It is very clear that petrus4 was *not* saying the words you are trying to put in his mouth. It is clear that he is referring to the fact that since PulseAudio is having such widespread trouble performing its core functionality (playing sound) across so many systems, it is badly designed. And I completely agree with this position, personally. A well-designed system would not have so many problems.
Oh, and as for "bug reports" mentioned above, they're not a cure-all, nor an appropriate thing to suggest as a response when buggy and incomplete software is shoehorned into distributions. I'm also not going to waste my time putting together bug reports for PulseAudio specifically when the general attitude is as I stated in my original post- ie. everything-but-PulseAudio is to blame. Don't try to push the responsibility for a chain of poor decisions onto the people affected by them. I'll submit bug reports to the projects that I think will do something useful with them.
And to close- I will clarify that one reason I find the PulseAudio design so poor is that it simultaneously assumed and relied on all applications and drivers being perfect, such that it could be treated as a drop-in replacement. Which clearly didn't work- and really never had a chance to do so. I can't think of one half-competent person who would design a system with a vast culture of interacting applications with this assumption. By my words, I'm *not* saying or implying that the PulseAudio designers are incompetent, I am just baffled that they approached the design and integration of their system without taking this properly into account. I'm wondering what influences led to this decision. I'm guessing somebody with the know-how was pressured in some way for a deliverable. Anyway, PulseAudio integration leads to a gigantic regression in audio functionality in distributions. A properly-designed system would not cause this. Smash-it-all-and-let-people-pick-up-the-pieces isn't a solid design methodology. Oh, and let me be very clear. I am more than qualified to comment on this aspect of the design. So let's leave off any "not expert enough" arguments, okay?
Anyway, I'm done. What does such an argument achieve anyway? I'll save my positive contributions for the day when I see the PulseAudio developers and distribution integrators say: "Um, sorry guys, we sorta screwed up. What's the best way forward?"