Sunday, July 31, 2011

Idea for PulseAudio and GNOME 3's Sound Menu; Default General and Chat Devices

After I post this blog post in order to get my ideas in one spot to help both sides of the equation understand this, I will be submitting bug reports to both PulseAudio and GNOME in order to get this upstream and hopefully it will make the cut for the next release of both.

At the current time, PulseAudio supports setting an application to use a different audio device which you can do through its pavucontrol program, and GNOME 3 supports none of this at all. This means if a new user is using GNOME 3 and wants to use a USB headset and talk to people while listening to music through speakers or play a game with sounds on and talk to people in TeamSpeak, they have to search online in order to find out how to do it.

However, with the current state of PulseAudio, adding such support to the sound menu could be done by giving each application a right-click option to switch to another device, but that would be a bit bothersome if the user used multiple VoIP programs such as Empathy, Skype, TeamSpeak and Mumble, and could confuse some people who don't even know what a sound card is. Plus, PulseAudio likes to "accidentally forget" about devices being default if you unplug them, which is annoying if you have a laptop and USB headset, for example.

:: PulseAudio Side ::

In order for my idea to work, PulseAudio will need to make some changes in the way it operates by supporting the setting of default devices (which will remain after a disconnect and switch to a fallback device only until the set device is plugged back in) to include a default General sound device and a default Chat sound device, or even better, generic device groupings with General and Chat as standard ones which applications can use. Others could then be added by the user for more complex configurations if desired.

Applications which interact with PulseAudio should then get a method to report whether they are Chat devices or not to PulseAudio and selected accordingly. Of course, not all applications will report this properly, which is a problem with Windows 7's implementation of this as well, so in order to resolve that and go a step beyond Windows 7 there should be an option per application to use either the default Chat or default General sound device, along with keeping the option to select a specific device for each, of course.

These, of course, would be a compilation of both a sink and a source which would be set separately as usual.

In pavucontrol the menu for retaining functionality and handling this could like something like the following.

* Use General Device

Use Chat Device

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

Use Internal Audio

Use Logitech USB Headset

Doing this at the PulseAudio level would allow for easier implementation and less redundancy in other desktop environments, hence the push for it here rather than only to be added in GNOME 3.

:: GNOME 3 Side ::

With PulseAudio's implementation in place, reflecting it in the sound settings would be the next step. I have made the following mockups for how that could look to save me typing and possibly losing what I mean in translation.

Also, for grandma and grandpa or parents who you set up with Linux so they would not kill Windows with viruses but who just bought a USB headset to talk to you and other family through Google Talk or Skype....

Optionally, just assume to set it as the default chat device and people can change it via the sound settings if they prefer it for everything or do it as a notification rather than a popup. Either behaviour would only occur the first time a device is connected to not interrupt persistent settings and/or annoy the user, of course.

For the sound menu drop-down, there could be something like...

... which would only show controls for the device group playing, or just Volume as usual if nothing but the general output is playing (and only one thing if the General and Chat devices are the same, etc, which could do with a bit of help from PulseAudio to sort that out).

:: In Closing ::

None of this should be considered the only way to implement this feature, of course, but a guideline and food for further thought. However, I think it would be a good step forward in making sound easier to configure in Linux (