Re: Planned "Sound Settings" improvements

[David Henningsson <david henningsson canonical com>]

On 10/19/2011 05:20 PM, Bastien Nocera wrote:
> On Wed, 2011-10-19 at 14:34 +0200, David Henningsson wrote:
> > On 10/19/2011 01:42 PM, Bastien Nocera wrote:
> > > On Wed, 2011-10-19 at 12:46 +0200, David Henningsson wrote:
> > > > Hi!
> > > >
> > > > Over the coming months, I'm planning to make some improvements to the
> > > > "Sound Settings" dialog. While my primary target is the upcoming Ubuntu
> > > > 12.04 release, I believe it will be of mutual benefit if this
> > > > functionality also becomes part of GNOME.
> > > >
> > > > To give you some background, I've been working on PulseAudio patches for
> > > > jack detection the last few months. Upstreaming of these patches are in
> > > > progress and will be a part of PulseAudio 2.0. These patches also make
> > > > PulseAudio expose more information, that makes it possible for us to
> > > > make the Sound Settings UI more user friendly.
> > > >
> > > > The main point of the redesign is to remove the hardware tab, and have
> > > > input and output tabs incorporate the information currently on the
> > > > hardware tab. There should be one row for every combination of
> > > > Port/Connector and Card, rather than today's practice of one row for
> > > > every card and a combobox for "Connector". The point is that since the
> > > > average user would think of "Headphones" and "Speakers" rather than
> > > > "Internal Audio Analog Stereo", we should present
> > > > Headphones/Speakers/etc to the user as the first thing he/she sees.
> > > >
> > > > There is a small mockup here:
> > > > http://people.canonical.com/~diwic/sound-settings/gvc_ui_final.jpg
> > > > The two bottom checkboxes will likely be removed. You should see it more
> > > > as "what" will be on the picture rather than "where".
> > > >
> > > > While GNOME might not want to have this feature before PulseAudio 2.0 is
> > > > released, I figured it'd be better to be too early to keep you in the
> > > > loop, than too late. So I'm reaching out to hear, well first and
> > > > foremost if this is something you're interested in, and if so, what help
> > > > is available when it comes to things such as making upstreaming to GNOME
> > > > go as smooth as possible. While I believe I can write most of the code,
> > > > I'm not used to the GNOME release cycle and workflow.
> > > >
> > > > As for getting the pixels right, I'm not a visual designer myself, but I
> > > > can probably get some help with that from within Canonical. (Also,
> > > > moving something two pixels down or rephrase a string, is of course
> > > > something you can change quite easy, should it not suit your preferences.)
> > >
> > > I'm fine with the idea, but I want to make sure that a couple of things
> > > are clear:
> > > - I'd like to see a proof-of-concept patch as soon as possible.
> >
> > Ok, I'm not sure what you mean. Could you clarify what should be in such
> > a proof-of-concept patch and what could be left out? (Nevertheless, this
> > will take at least a few weeks due to the upcoming travel on my own part.)
>
> Something that kind of works. I won't be doing any code review on it,
> but it would give us a better grasp of what the panel would end up
> looking like, and see how it behaves with real hardware.

Ok. As you probably understand, that will take some time as that would 
require most of the code to be written.

> > > Your
> > > mockup shows 6 outputs, there would probably be at least double that in
> > > most cases,
> >
> > A typical laptop would have only two: "Speaker" and "Headphone". (And on
> > the input tab, "External Microphone" and "Internal Microphone".) There
> > could be a few more - HDMI, SPDIF, USB Headset etc, but I believe more
> > than six would be less common.
>
> Except that if you plug in one external 5.1 sound card and a webcam with
> a microphone you end up with a bazillion combinations of outputs. I want
> to see how those changes would impact the number of items we would see
> in the list, and whether it actually makes it more usable or not.

So in practice, the only cards that have more than one port/connector is 
the internal on-board sound card. An external 5.1 and a webcam would be 
one additional item in the list each.

> > > and it's not clear to me how you will show the interaction
> > > between port/connector card for output/input (eg. if I select SPDIF
> > > output, can I select analog input for that particular card?).
> >
> > I'm not completely sure I understand your question, but...
> >
> > Port/connector selection is implemented as setting a bunch of ALSA mixer
> > controls. Changing ports/connectors on the output side does not affect
> > the input side (and vice versa).
>
> You need somewhere to say "I want to use the SPDIF output and the analog
> input on this device" as it's not something that we can detect at all.
> Right now, it's tightly bound to "cards" (eg. things in the hardware
> tab). Where would we show it now?

Current behaviour is to set (and show) profile on the hardware tab and 
port on the input/output tab. In suggested design, the profile is set 
through a combobox on the input/output tab (see the mockup).

We need a way to set and show the card's active port, that is correct. 
Probably we need a checkbox (or a GtkSwitch?) to activate/deactivate the 
current port. We could have this either in the list next to each item 
(then the checkbox would serve as indicator as well), or we could mark 
the inactive items in the list somehow - and have the checkbox as a 
configuration item for the device.

> > It is relatively rare for a profile selection on the output side to
> > affect the input side, but it can happen, e g on bluetooth headsets
> > where a "voice" profile would be full duplex and a "Music" profile would
> > be half-duplex (but higher quality).
> > Maybe a warning is best here? E g if the user switches from "voice" to
> > "music", we could have a dialog saying "This will disable bluetooth
> > microphone. [OK] [Cancel]". I'm open for suggestions though.
>
> That's a good idea, especially as we could detect that the Bluetooth
> headset is being used by some VoIP software for example.
>
> > > - Patches should go in bugzilla as soon as possible. I really don't want
> > > to see a code drop.
> >
> > No problem. I assume patches should be GPLv2+ (that's what gvc is
> > written in today) and submitted against the master branch of
> > git://git.gnome.org/gnome-control-center - is this correct?
>
> That would be best, yes.
>
> The summary is that, yes, interested in the changes, but I cannot tell
> you that they will get merged if they end up being too disruptive to the
> codebase (and show up late), or if they create regressions in terms of
> usability.

Ok, I understand that. Well, increase usability is what we all want, so 
should that not be the case, I've failed miserably. However, if the 
changes are too late and disruptive in a Gnome cycle, I assume they will 
be considered for the next version of Gnome instead?

--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic