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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
