Jackdbus and pulse

[David Henningsson]

On 01/10/2013 12:46 AM, Len Ovens wrote:
> We have lately been having trouble with our pulse/jackdbus setup. When I
> first installed 12.04 starting Jackdbus with qjackctl or jack_control
> would stop whatever pulse was doing and use the port. Somewhere between
> there and here this no longer works right. Sometimes if the session has
> just started, and pulse has not been used to stream anything, jack still
> works this way, but for sure once pulse has been used or is streaming,
> Jack will fail to start because it can not get access to the device pulse
> is using.
>
> What is supposed to happen: Jackdbus uses dbus to tell pulseaudio to
> release the device jack wishes to connect to. This does appear to happen,
> at least audio stops going to the device and the timer on the streaming
> app stops just as in the case of a blocked port. However, jack fails to
> get the port. (once in a long while it "just works")
>
> I have played around with this and there is a hack that will work. This is
> not a fix. When setting up qjackctl, there is a tab called "Options". On
> that panel there is a line with "Execute script on Startup". If this is
> enabled and the line:
>
> pasuspender sleep 5 &

Interesting; I didn't think this would work, it probably shouldn't - 
pasuspender should suspend all sinks, including the JACK sink.

It must be because the JACK sink is created *after* pasuspender starts, 
would be the reason why it is not suspended properly.

> Added, everything just works so long as jack is started with qjackctl. I
> tested this by using Audacious to play some songs through pulse. On
> starting jack with qjackctl there is a brief silence and then the stream
> switches over to jack-sink and continues to stream through jack. Stopping
> jack works just fine too with the stream switching back to the device.
>
> Davis I CCed this to you because I know you have a better understanding of
> pulse than me. Would you (or anyone) know if pasuspender uses dbus to tell
> PA to release HW devices?

It uses PA's native protocol (which in turn uses unix sockets for 
communication, and SHM for memory tranfers).

> If so then it would appear that PA is working
> but jackdbus is not waiting long enough, or that PA is ack the dbus
> message before it has completed releasing the port. Maybe it is the right
> thing for PA to do even... Dbus may not like to wait around while PA does
> stuff. Anyway, an answer to this will give me a good idea which package to
> apply the bug against... and maybe see if a patch can be made. My
> inclination is to bug jackd2. The patch would be to delay jackd for a
> short period (half second?) after getting a dbus ack before attempting to
> use the device. I will try to figure it out myself, but am not great with
> c++, most of my programing has been c, and not for a while now.

There is indeed a timing issue, which I never tracked down and fixed. To 
be pragmatic, I guess you can insert random delays wherever it works, 
but beware - timings are very different between hardware, so the timings 
that work for you might not work everywhere else.

To fix it in the right way you need to figure out why this happens in 
the first place - I mean, it could be either one of these three:

1) PulseAudio does not release the device before answering on dbus
2) Jackd2 does not wait for dbus answer before opening the device
3) The kernel (or alsa-lib) does not release the device properly before 
returning from snd_pcm_close.


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic