On 09/30/2011 10:44 AM, Colin Guthrie wrote: > 'Twas brillig, and Taylor Hutt at 28/09/11 18:29 did gyre and gimble: >> In this case, I am part of a team working to make a shipping product, >> and there are time constraints which >> do not afford the time necessary to do that, _and_ to make forward >> progress to get the sound system working >> across a constantly increasing variety of hardware. > > While I accept your standpoint, I'd also point out that PulseAudio has > been dealing with a variety of hardware for several years. We've got > extensive support for probing the many different kinds of mixer setups > to come up with a valid mixer element chain for volume controls and for > switching to different outputs (headphones vs. speakers, internal vs. > external mic etc). > > If time is of the essence for you, I think it would be highly > adventitious to leverage years of experience from people rolling out > solutions to varying hardware and reusing a relatively mature bit of > software that already achieves probably 90-95% of what you'll need. To > me, that would seem like the must prudent approach to something with > time constraints. If anything I'd suggest the opposite would only be > true if there were no time constraints at all! Folks, let's be fair here. No software is perfect, and it would make sense to point out the flaws and shortcomings of PulseAudio as well as its advantages (which other people here have already covered). First, look at the "What's next" section of the 1.0 notes [1]. That points out what we think are the most important shortcomings of PulseAudio currently, one of them is "Routing infrastructure": while it is possible to write your own policy modules today, we're still lacking a really good solution for handling device priority in combination with hotplugging in combination with user configurable overrides. Let me add "complexity" as the other major shortcoming of PulseAudio. When something goes wrong, it is often not that trivial to fix it. Take e g the "eternal rewind" problems I have been working on for quite some time, and that I still have not been able to resolve completely. Also, there are context switches at every data package (client -> PA main -> PA I/O), and designing a proper plugin system would be so difficult that none of us who are currently active here feels like taking it on. Should you run into complex bugs, that can be a significant risk for a project on limited time budget - of course that is true for *any* project, but PA is used in so many environments you must think twice before doing anything that might cause regressions in other use cases. However, at the end of the day, PulseAudio is still the most feature rich sound server we currently got on the desktop. If you're looking for a lot of interesting features, you're going to want PulseAudio, but it comes at the cost of the complexity needed to maintain all other peoples' favorite features as well. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic [1] http://www.freedesktop.org/wiki/Software/PulseAudio/Notes/1.0
