[pulseaudio-discuss] Device reservation improvement suggestions

[Zeno Endemann]

On 19 Oct 2015 09:37:05 +0200, David Henningsson wrote:
> On 2015-10-04 17:05, Zeno Endemann wrote:
>> Hi,
>>
>> I have two suggestions how the device reservation can be improved for
>> app developers wanting to have exclusive access to an alsa card:
>>
>> 1.
>> I knew about this scheme only by accident, so I think the
>> discoverability should be improved. Adding a few lines to the PA
>> developer documentation site ([1]) with a link to [2] would already be
>> good (it took me quite a while to even find [2]).
> 
> Good idea, added now.

Thanks, much better now.

> 
>> Since the most important sound server (PA and jack, right?) are using it
>> and thus it having a good de facto adoption I furthermore suggest adding
>> the spec to the freedesktop.org specifications page. Should I ask about
>> this on the freedesktop mailing list?
>>
>> 2.
>> The spec implies that the reservation is for a whole device (ie. alsa
>> card), so I believe a well-behaving client should not touch a reserved
>> alsa card in any way. But PA only uses the reservation for PCM streams,
>> not for the mixer controls of the card. My suggestion is either fixing
>> PA (my preference) so that it reserves the card before writing any
>> changes to the mixer, or at least making it clear in the spec that the
>> reservation is only for all PCM devices on the corresponding card.
> 
> I agree that PA should reserve the card before opening the mixer. 
> Patches welcome :-) Although you might want to synchronize with Tanu who 
> recently talked about closing the mixer when we lost access to it, that 
> sounds like something that touches similar parts of the code at least.

I had a quick look, but for me to patch it I'd first need to understand
the PA module system better. The module-alsa-card.c (assuming that is
the correct place) already reserves the card in pa__init, but gives up
the reserve after initialization. Extending that so it reserves until
pa__done is easy, but one would also need to deal with how to make that
module properly give up and reacquire a card. Doing that cleanly seems
not that easy without knowing how exactly the module interacts with the
core. Also there are questions like should a reserved card temporarily
remove all profiles, so they cannot be switched to etc.

Maybe I'll look more into it, but no promises ;)

> 
> (Side note: I would have liked to see the device reservation protocol on 
> the system bus instead of the session one, but that's likely too late to 
> change now)
> 

I actually considered also suggesting that change, as for a global
resource it makes logically more sense, but I can also see the practical
advantage of not having to rely on D-Bus being properly configured for that.


Cheers,
Zeno Endemann