Colin.Guthr.ie Illegitimi non carborundum

29Jun/091

What’s cooking in the Pulse Pot

While I've done a bit of pavucontrol hacking, the most interesting stuff is happening in pulse itself, specifically in relation to better KDE support...

KDE has a fairly robust audio framework these days. It's still got several kinks and missing features, but it's a good basis for apps going forward. Sadly pulse has had a pretty rough ride here. There are two "backends" in common usage with Phonon on Linux (it has configurable backends originally intended to allow cross platform support - e.g. DirectX on windows and QT on Mac OS). Personally, I think that this is a bad idea - while I support diversity, having a single backend that is subsequently developed by everyone and made rock solid is IMO more important than diversity - certianly in the initial stages. There are also VLC and mplayer backends too... I think this just muddies the water, regardless of the quality of these specific parts.

QT originally developed a GStreamer based backend for use on Linux. This is, for me, the right approach as the GStreamer library seems ideally suited for this. Unfortantely the KDE community didn't really pick up on this and rather than develop and improve the GStreamer backend (which was pretty early stage and could definitely done with improvement), a Xine based backend was created instead. While this works fine for audio decoding, I don't think that this is the right approach longer term, but such is life.

The sad thing is that Pulse support in Xine is not that great right now and causes a lot of problems for people. Improving this support will go a long, long way to gaining better acceptance of PulseAudio by the KDE community.

Speaking of which, this is where the rest of my interest lies - improving KDE integration.

Phonon has a settings GUI that lists various output devices, including those not currently connected, and allows the user to rank the devices in order of preference. These "devices" also include output special output drivers such as the PulseAudio plugin. Now as pulse is a complete management system, it makes very little sense to include it like any other physical device and order them - when a user uses pulse on their system, they want to use it for everything (of course they may choose not to use pulse at all and that's fine too - even if I wouldn't recommend it!). In Mandriva we've long since patched the settings GUI to detect if the user wants to use pulse and simply hide all the other devices - the user is directed to use pavucontrol to move their streams around. This works OK, but it's clearly not the ultimate solution! Any self respecting KDE zealot would never run pavucontrol (it's a GTK app!) and while my own desktop is a horrible mix of just about every DE under the sun, I appreciate many people want to be "pure"!

So what do I want to see? Well, when it's in use, I'd like to off load pretty much all the handling of audio devices to pulse. It should take care of handling the device preferences and the automatic switching to higher priority devices when they become available and/or are reordered. The routing system in pulse is alreay setup to do a lot of funky things routing wise (like automatically moving music streams to RAOP devices, or VOIP streams to Bluetooth headsets), although a manual priority list is not currently supported. I am aiming to create such support for a priority list in pulse and expose it via a protocol extension. In the Gnome case, it's likely that this priority list either completely masked from the user and the existing routing stuff is used in it's stead, or that said existing routing stuff is evolved to just become a manager for managing the priority list internally. The final design decisions here are not finalised, but there will be some sort of working solution that will present itself!

In the mean time, I've started development on "module-device-manager" which acheives the rather simple goal of remembering all the past and present devices pulse has seen and allow querying of that list. As a neat little side effect, it can be used to edit the descriptions given to devices so for shits and giggles I implemented this renaming support in pavucontrol.

Here is a quick screenie:

Renaming a device in pavucontrol

Share and Enjoy:
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Yahoo! Buzz
  • Twitter
  • Google Bookmarks
  • Identi.ca
  • Slashdot
  • aapgorilla

    Very nice, I also hope that volume control for all devices can be done with the kde hotkeys (and still have the OSD too.