FESCo Meeting Summary for 20090424

[Lennart Poettering]

On Sun, 03.05.09 12:37, Adam Williamson (awilliam at redhat.com) wrote:

> 
> 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.

There are no regressions in comparison to the the SPDIF status quo
ante. Accessing iec985:xxx was previously available and basically still is.

> > 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.

Analog surround support in ALSA mixer has been completely broken since
time began and still is. I cannot tape over that fact in PA.

When used for surround sound the ALSA mixer knows channels such as
"Rear Front Left" and "Side Front Left". That is broken. The ALSA
mixer *never* worked for surround sound volume control and still
doesn't. PA synthesizes software volume control when doing surround
playback which is currently the best option we have, and works even if
it is not optimal. And certainly is better then the status quo ante.

> 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.

ALSA should switch the necessary controls when we open the
"surround51:" devices and suchlike. If it doesn't switch those
controls then please file a bug against ALSA.

> 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.

Nice idea. Completely broken, as mentioned above.

> 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

No. It's not available. The ALSA mixer is completely broken for
surround sound. 

> 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.

Nah. using this is a misuse. You always should access SPDIF via the
'iec985' device, which is what PA does. It will switch the appropriate
controls automatically and lock them and switch them back after use.

The fact that these controls are available is an implementation detail
which should be and is hidden by PA.

> aethod 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.

This distinction is nonsense.

It's the same as method 1. All sound cards have controls to configure
a few spdif settings and as long as you access the device via
"iec985:" alsa should configure everything as necessary.

> 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.

This is wrong. PA handles spdif correctly. There is not
regression. And PA handles the surround mixer situation better than
the raw ALSA mixer. There is no regression. 

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4