Tuesday, August 12, 2008

HAL: fixed device locking

Some days ago I had a discussion with Matthias Kretz at the Akademy 2008 about HAL, the handling of audio devices in HAL and the needs/requirements from the perspective of phonon.

One aspect was that phonon needs to find out of some other tool already uses a audio device. The HAL device locking would be a solution to detect this. I took a look at the HAL code for device locking and while playing around with the interfaces I wondered why it didn't work as it should. The lock information (info.locked* keys) where never removed if the lock owner died or exited without unlock the interface again. The handling was also broken if someone requested more than one lock (e.g. two or more different devices).

I really wonder why there was only one bugreport about problems with device locking (if the lock owner dies). Did nobody ever used these interfaces?

I've wrote a quik patch to solve these problems. As first I changed the hashtable which contains the lock info from key={lockowner}/value={device} to key={lockowner}/value={list of devices} so that locking multiple devices is now possible. And the other part of this patch is to remove the lock based on the old_service_name (and not the new_service_name) on NameOwnerChanged events from DBus to solve the 'lock owner died' problem.
Tech Tags:


Sven said...

Would this explain why I never get sound for my local install of KDE 4.1, while the system-wide is up and running?

Kevin Kofler said...

IMHO all this is just broken by design. Apps must be able to play sound concurrently, every solution relying on locking is solving the wrong problem. The right solution is to use mixing, either with dmix or with a sound server such as PulseAudio. Only the sound server should be accessing the hardware directly. In the dmix case, nothing should be doing that, as ALSA handles it internally. PulseAudio looks like the best solution at the moment, because it has not only an ALSA plugin very similar to dmix, but also a native protocol and ESD emulation. Fedora uses PulseAudio by default throughout.

Kevin Kofler said...

Oh, and PulseAudio also supports network transparency.

Matthias Kretz said...

Hi Kevin,

that's a misunderstanding of what this sound device locking can be useful for. Of course we normally want to use pulseaudio or dmix to access the device. But there's also jack or other low-latency applications that might want the direct hw access. In that case it would be nice of them to tell everyone else via HAL that they grabbed the device for themselves so that the application can either tell the user why it cannot use the soundcard (and how to fix it) or just use a jackd connection to do its work.

PulseAudio also wants to use the hw access, so it would lock the HAL device, too. And then other apps would know they can't use dmix but pulse.

OTOH an application playing with dmix won't lock the device...