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
