FESCo Meeting Summary for 20090424

Sun May 3 19:37:56 UTC 2009

On Sun, 2009-05-03 at 20:00 +0100, Bastien Nocera wrote:

> > That just makes me question even more your competence to be doing the
> > design; if you manage to come up with a design for a mixer application
> > without considering the importance of digital output, well. Er.
> > That's...um. My output device is connected digitally. So are zillions of
> > others. That's why soundcards ship with S/PDIF outputs. Even cheap
> > crappy onboard sound, where the manufacturers would gladly save a cent
> > any old way, universally include S/PDIF now - because people want it.
> > How were you expecting us to hear any sound?
> > 
> > I suspect this whole process was managed by people who are great at
> > interface design, and great at the software side of audio/video (which I
> > know you are), but perhaps didn't think hard enough about what people
> > actually do with audio hardware.
> 
> I call BS here. PulseAudio never supported SPDIF outputs properly
> before. So we really haven't made the experience any worse.

PulseAudio didn't before this cycle, no. I'm talking about regressions
compared to the tools included and easily accessible in F10 and previous
releases, not just in the Pulse features. I'll talk about this a bit
more further down.

> > > The only use case(s) that we haven't catered for are for people who want
> > > to record things, and the sound card has more than 1 input. 
> > 
> > No, not correct at all. You haven't yet catered for people who want to
> > *monitor* (rather than record) an input channel
> 
> What on earth is "monitoring" an input? 

Just looping the sound from an input around to the output in real-time,
not recording from it. In implementation terms it's mostly the same as
input switching, but in *usage* terms it's a distinct case - take the
guy from this list who wants to listen to sound from an external device
via the line-in on his card.

> There's a volume level in
> gnome-volume-control, we didn't have that before. I stand by the
> statement I made above. If I didn't understand the problem properly,
> feel free to hop onto the fedora-desktop list and explain what's missing
> from:
> http://fedoraproject.org/wiki/Features/VolumeControlContinued
> 
> > , people who have digital
> > outputs, or people who have analog surround sound setups (the Logitech
> > Z-5300 has been in production for about seven years for a *reason* -
> > people buy this stuff).
> 
> Analog surround will be supported by the next version of
> gnome-volume-control. You had to poke in ALSA to get this working
> before, now you can use pavucontrol, or a one-liner in pacmd to fix
> that.
> 
> Not a regression then.

It is a regression, because in previous releases, we shipped an ALSA
mixer by default which *did* allow this functionality. Sure, it allowed
it with a really crappy interface, but it allowed it.

(Is this next version of g-v-c coming soon enough for us to shove it
into F11 at release? That would be nice.)

Your mention of pavucontrol seems to expose a bit of confusion, because
we have Lennart saying "pavucontrol should have been dropped from the
default install the minute the new g-v-c was pushed into Fedora. We
forgot to do that. We should do it now. End of story.", and William
saying "The fact that it is still currently in the menus is
almost certainly an oversight". So are you guys saying pavucontrol
should be installed by default, or not? Do you agree with Lennart and
William on this?

For now I'll act on the assumption that the counter-proposal is to drop
pavucontrol and ship only new g-v-c by default, since that seems to be
the majority position on your side. If that's the case, any
functionality provided by pavucontrol but not g-v-c is not important, as
it wouldn't be installed by default.

> Seriously. The discussion started because there were regressions, then
> you go on accusing us of missing features that were never properly
> supported in the first place.
> 
> SPDIF and analog surround weren't supported by the crappy mixers we had
> before, and they're not supported now. But now we have the framework to
> make those work. I see that as a great step forward.

This just isn't factually accurate.

Analog surround: on every card I've ever seen, this is how this is
implemented.

The card has the usual set of jacks - line / speaker out, line in, mic
in, maybe an aux in or something.

There is a switch-type mixer control which enables or disables analog
surround. When it's enabled, two of the jacks, which are usually line-in
and mic-in or something, instead become the extra outputs needed for
surround output: one for the rear speakers, one for the sub and the
center channel. When it's disabled, they have their original functions.

There's also (usually) some extra volume range-type elements which let
you control the volume of each of the parts of the surround system
separately, so you can compensate for how far away your surround
speakers or sub are to make sure the sound is balanced.

These elements are all exposed by ALSA, so any ALSA mixer - including
the old gnome-volume-control - can enable this functionality. Yes, it's
a crappy interface, but the function is available, and many people at
this point know how to use it. We shipped an ALSA mixer by default in
F10. The proposal of those opposed to the compromise approved by FESco
is not to ship one by default in F11 (and, as far as I can tell, not to
ship pavucontrol either). Hence, this feature was exposed by a graphical
application installed by default in F10, while under that proposal, it
will not be in F11. That is a regression.

Digital output: there are two main ways of implementing this.

Method 1: there is a switch-type ALSA mixer element which enables or
disables digital output (usually labelled IEC958 Output or something
similar). Hence any ALSA mixer allows you to enable or disable digital
output. As discussed above, this would therefore be available in F10,
not in F11: hence, regression.

Method 2: the digital output is implemented as a separate playback
'interface' (sorry, I don't know the correct technical term for it) by
ALSA, so to output to it, you have to do something like 'mplayer -ao
alsa:device=spdif', or create a little ~/.asoundrc file that sets up
this routing by default. Indeed there was no GUI way to do this in F10,
so the implementation of support for it via PA's profile system is an
improvement, and a really nice one (that I personally benefit from). So
there is no regression in this case.

FWIW, I believe Creative cards, which are likely the most popular
expansion cards, usually use the switch-type mixer element method. I'm
not sure which method Intel onboard hardware, which is probably the most
common type of sound hardware taken all-in-all, use.

So, summary: in two out of three of the cases for analog surround output
and digital output, the anti-FESco-compromise position results in a
regression from functionality exposed via a GUI tool installed by
default in F10. In one case, it results in no benefit, because g-v-c
doesn't support profiles yet and they apparently don't want to ship
pavucontrol any more.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net