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. _______________________________________________ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
