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
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
