[pulseaudio-discuss] jack soundcard reservation behavior

[Stéphane Letz]

Le 31 juil. 09 à 22:57, Lennart Poettering a écrit :

> On Fri, 31.07.09 13:46, Fernando Lopez-Lezcano  
> (nando at ccrma.Stanford.EDU) wrote:
>
>> One question though, shouldn't pulseaudio have printed something when
>> jack quits? (with -vvv) It does print when jack asks for the card.
>
> 0.9.16 does, 0.9.15 doesn't take notice of that.
>
>>> So with F12 you start jack, and rb stops and then you quit jack  
>>> and rb
>>> continues automatically.
>>
>> Great. But do the streams stop playing or do they continue playing
>> "muted" while the card is "borrowed" by jackd? If I use the pacmd
>> suspend 1 trick they continue playing (muted, or sent to the  
>> equivalent
>> of /dev/null, I don't know).
>
> The effect of pasuspend and this reservation lgoci stuff should be
> mostly identical: the device is forcibly suspended playback
> freezes. The client apps are notified about that and could show this
> in the UI but almost no app doesd that and for them time just appears
> frozen.
>
> or with other words: not a single sample is dropped when PA's device
> access is suspended.
>
>>>> [*] for example it would allow for currently playing streams to  
>>>> be moved
>>>> to a dynamically loaded jack plugin without missing a beat (or  
>>>> rather,
>>>> with a very short interruption). Part of this is also  
>>>> implemented in my
>>>> current script.
>>>
>>> I'd love to make PA automatically load a jack connectivity module  
>>> when
>>> JACK is started up. A simple way to implement that would be by
>>> watching for JACK's service name to appear on the bus. But
>>> unfortunately jack doesn't work that way and the running daemon does
>>> not take name on the bus.
>>
>> Couldn't jack notify when it is ready? (and furthermore when it is  
>> about
>> to quit). It is already talking on dbus with pulseaudio... I'm pretty
>> sure things are not so easy :-) It would also have to be something  
>> you
>> could turn on/off when jack is started, maybe that would be the deal
>> killer.
>
> Taking a name on the bus would be the perfect solution, since it makes
> sure PA knows exactly when jack becomes available and when jack goes
> away again. Also if jack dies abnormally D-Bus would clean up the name
> automatically so this would even be very robust.
>
> Lennart
>


OK.

So I guess the "dbus_bus_request_name/dbus_bus_release_name" pair of  
functions has to be used right?  (I see that PulseAudio register  
itself in "register_dbus" function but there is no symetrical  
"unregister_dbus" that woud use dbus_bus_release_name?)

Is the dbus_bus_release_name mandatory? I mean I am thinking calling  
dbus_bus_request_name *after* the JACK server has been started (to be  
sure the PA JACK client can then register) and calling  
dbus_bus_release_name *before* JACK server stops, but then how to be  
sure the "stop" notification has really be received/handled by PA  
before actualy stopping the server?

Thanks

Stéphane