On 05/02/2013 04:28 PM, Tvrtko Ursulin wrote: > > Hi David, > > On Thursday 02 May 2013 12:55:05 David Henningsson wrote: >> Just had an idea which I'll write down here before I forget it >> again...and I'm not saying I'll implement this anytime soon either, but >> here goes: >> >> There is a device reserve protocol between PulseAudio and JACK2 - when >> JACK needs the sound card, it'll send a dbus message to PulseAudio and >> grab a name in D-Bus. >> >> However, there are plenty of applications who like to access ALSA >> directly, without going through JACK2 or PulseAudio. By making a >> "reserve" plugin, we could have this functionality for those apps too. >> >> In practice, if the app usually opens "plughw:0" or "hw:0", it could >> instead open "reserve:plughw:0" or "reserve:hw:0" to also reserve the >> device from PulseAudio usage while the device is open. Meanwhile, >> PulseAudio is free to use other audio devices (which is not the case >> when using e g pasuspender). >> >> How does that sound? > > If I understand correctly you are saying essentially this: > > 1. There is an existing device control protocol which works over DBus. > 2. Your idea is to add a equivalent device control protocol using ALSA PCM > plugin (well in fact not add but create a new proxy interface to it). > > Is that right? If so, how do you provide this functionality to existing > applications without teaching them about the reserve plugin? Many ALSA applications lets you specify the device string on e g the command line or through a configuration interface. So the end user would configure the application to use "reserve:plughw:0" instead of "plughw:0". The applications that do not follow this will have to be taught, and they have a extremely simple way to implement it - just add "reserve:" do the device string. > > And if you have to modify the applications, is the only advantage then that > you do not have to add DBus dependency to them? Or a PA dependency to talk > directly to the server? If so then this solution feels a bit kludgy. > > Perhaps you would want an extension to snd_pcm_open (or whatever, I am going > from vague memory here) to have something like "SND_PCM_EXCLUSIVE | > SND_PCM_NOTIFY_BUSY_OPEN" mode (if the former is not implied) which would > notify the original owner that the second application is attempting to open > it. Perhaps using SIGURG or something while returing -EBUSY or something to > the caller signalling they should retry. Not sure if this would be doable > completely in userspace so I might be leading you toward a generic > kernel/glibc solution here. :) > > What about the policy control as to which applications are allowed to take > over? It sounds sub optimal to allow any ALSA application which knows about > this new plugin or other release mechanism to take over just like that. That > would create a bit of a mess. That is a valid point - but so far the only app that can *give away* a sound card is PulseAudio. All of the others (at least in the simplest scenario), can only *take* a sound card. If the card is already used by some app that can't give away its sound card, it's going to be -EBUSY as usual. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
