The Great Pulseaudio Mixer Debate: a modest (productive) proposal
William Jon McCann
william.jon.mccann at gmail.com
Mon Apr 27 20:09:12 UTC 2009
On Sun, Apr 26, 2009 at 4:43 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
> On Sat, 2009-04-25 at 03:34 +0200, Lennart Poettering wrote:
>> On Fri, 24.04.09 23:48, David Woodhouse (dwmw2 at infradead.org) wrote:
>> > I don't think we're just going to decide that Fedora doesn't care about
>> > these users -- and from what I saw today I don't think it's likely that
>> > the PA folks will decide that they _do_ care.
>> > So it looks like if we keep PulseAudio as the core around which Fedora
>> > audio support is based, we're _always_ going to need to keep something
>> > extra to fill the functionality gap.
>> Oh great. This sounds like an invitation to stop working on cleaning
>> up the volume control situation entirely. If we never can get rid of
>> the old cruft and need to prominently feature it in all future release
>> then why even try?
> I believe that our user interface people are good enough that they can
> find some middle ground -- somewhere a long way from the oft-cited
> alsa-mixer-of-doom, and much closer to the nice but oversimplified F-11
> implementation of gnome-volume-control -- but which actually lets people
> have better control over their hardware _when_ they need it.
> I don't believe that we're really limited to one extreme or the other.
> So no, I don't believe that it's an invitation to stop working on it at
> all. It's merely an invitation to do better.
Actually, I think this is pretty close to the UI we want and, modulo
the input selection and one or two other technical limitations that
are being worked on, it should be nearly complete. I designed it with
help from Matthew Paul Thomas - and with oh a bit of inspiration from
a popular and highly regarded operating system. I feel very strongly
that we shouldn't be compromising our designs to cater to the lowest
common denominator of broken hardware and drivers - and definitely not
for something as easy to fix as a unimplemented feature.
In general, in order for our design and development process to succeed
we need to illuminate the dark - not dim the light to match. Or
alternately, in my opinion, we will never be successful if we try to
design software based on a unanimous consensus (of working features).
I think Lennart has a wiki page somewhere that describes some of the
current problems and how they should be addressed.
More information about the devel