[Ayatana] Pulseaudio / Sound Indicator usability issue

[Ara Pulido <ara@xxxxxxxxxx>]

Hello all,

Lucid is looking great in terms of user experience, but there is an
issue with the sound indicator that keeps bothering me.

*The issue:*
When I plug a USB headphone, by default, pulseaudio starts outputting
directly to the headphone but it does not get reflected in the selection
of the output device in gnome-media and, therefore, changing the volume
there (or the sound indicator) does not get reflected in the volume.
Even worse, if the sound was muted before plugging the headset, the
headset won't be muted, and, as the sound indicator is supposed to "Mute
All" devices, it gets a bit confusing.

I raised the problem to Conor Curran a while ago and we decided to raise
the problem to the PulseAudio developers. After a long IRC conversation
(which I have posted at the end of this message for reference) it turned
out that it wasn't a bug, but just the way audio routing works in
PulseAudio. There is a blog post [1] explaining how PulseAudio handles
routing.

Although this is "how PulseAudio is supposed to work" I still think this
is an important usability issue in Lucid. An end user (and me!!), when
plugging a USB headset, would expect the sound to come out from the
headset (which is how it works now) but, also, would expect to be able
to control the volume with the indicator sound.

I expect a lot of duplicate bugs when Lucid gets released. Conor, be
warned ;-P

Cheers,
Ara.

[1] http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/

------------------------------------------------------------------

<ara> if I plug my USB headphones, by default, pulseaudio starts
outputing directly to the USB, but it does not get reflected in the
selection of the output device in gnome-media, and, therefore, changing
the volume there, does not get reflected in the volume
<coling> OK, interesting. So when you plug in the USB it becomes default?
 (i.e. pacmd stat lists it as the default?)
<ronoc> PA does not emit a server event telling that the default sink
has changed
 very producable
<coling> OK cool :)
 Should be an easy fix then.
<ronoc> good stuff
<coling> (I presume such an event/subscription is available
infrastructure wise, but it's just not hooked up right?)
* coling tries to reproduce here
<ronoc> i would imagine so
<coling> Hmm
 OK, what makes your newly plugged in device the default?
<ronoc> don't know
<coling> That is not something that is restored for me.
<ronoc> but the audio output is automatically redirected to the headset
 without the server msg
<coling> i.e. set internal device to default, plugin USB, set it as
default, unplug, (internal is now default), replug (internal remains as
default)
 Ahhh
 Right
 OK, that's not the "default" device changing
 It's just that PA remembers the device for that particular application
because it's been moved via the API to a particular device before.
 It's not a system default, it's a stream specific default.
<ronoc> ahh okay
<coling> To be honest the whole routing logic in this regard is pretty
broken IMO.
 I've been trying to campaign mezcalero to let me change it but he's not
budging so far (I'll win eventually by being generally annoying tho' I'm
sure!)
 If you want to know more background you can read up here:
 http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/
<ronoc> its a bit confusing and from the app dev side limiting in that
when the headset is plugged in the audio is redirected but then both
sliders gvc and indicator sound are in effect useless
 from the user perspective its a bug - which i suppose there really is
not other kind of perspective :)
 i started to read this a few weeks back - will do today promise. a bit
snowed under with the new job
 -t
<coling> It's not really a bug sadly. The g-v-c[-a] tools are looking at
the default sink and controlling it. There is nothing else they can do
really as several streams may be active at any given time so which
device should be "controlled"?
 That said, mezcalero did talk about putting some smarts into some part
of the chain to try and guess what device the user wants to control.
 e.g. if there are streams active on only one device, it's likely the
one you want to control.
<ronoc> I understand but from using it it comes across as a bug
<coling> Other things like buttons on USB headsets need Xinput2 fixes
from gtk to work.
 (so they can be tied to the device they are physically attached to
ratehr than just producing generic vol up and vol down events)
<ronoc> cool might talk to Cody to see if we can do some of those fixes
<-- mlankhor1t has quit (Ping timeout: 260 seconds)
<coling> FWIW, if my proposal is taken on board, if you set the system
wide (not application or role specific) default device, then things will
work as you imagine.
 This is without other changes.
 So it's another reason why I think I'm right.
<ronoc> great +1 from me :)
<ara> coling, thanks a lot for your explanation :)
<coling> no worries
<coling> I shoudl say that it would still be possible to plugin e.g. a
USB headset and only want to use it as default for a particular role
(e.g. VOIP). In that case g-v-c would still control the overall system
default so wouldn't control it, but such is the price of flexibility! If
the heuristic stuff mentioned above to guess the most appropriate device
to control was implemented then it would fix that issue up.