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