Le 31 juil. 09 à 22:57, Lennart Poettering a écrit :
On Fri, 31.07.09 13:46, Fernando Lopez-Lezcano
([email protected]) 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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss