Bug 872362

...in jackuser and audio groups FWIW.

Hi Ian,

can you try with a downgraded jack-audio-connection-kit-1.9.8-11.

I can reproduce this here and it seems jack may be behaving as per bug 827748 Could be a malformed Dbus request.

If you could post the output of both jack and pulseaudio before and after that would be great.

pulseaudio --kill; pulseaudio -vvvv 

Does jack work for you when you turn of pulse completely? 
echo "autospawn=false" > ~/.pulse/client.conf" && pulseaudio --kill

Does it work in non-dbus mode when pusle is off.

thanks

Created attachment 637262 [details]
Jack output - dbus enabled

Jack output, 'start' is after the first connection graph change.

Created attachment 637263 [details]
pulse output with dbus enabled

I notice this looks slightly different to the output I originally posted, I think killing and restarting Pulse causes this, as I did see different behaviour in earlier testing when killing pulse prior to starting Jack (trying to see if phonon was involved).

It's actually possible that killing pulseaudio does something that causes the dbus connection to succeed afterwards (even though pulse restarts). I've just tried it in the Live KDE spin and that seems to be the case. Jack also works there with dbus disabled and pulse disabled (as you might expect), but dies inside the VM, so I think the crash under the VM is a bit misleading and probably not of /very/ much concern (Jack started there with pulse disabled runs for a brief time then dies after lots of xruns).

This is the 30 Oct Live image with jack installed via yum today:
qjackctl-0.3.9-3.fc18.x86_64
jack-audio-connection-kit-1.9.8-12.fc18.x86_64
jack-audio-connection-kit-dbus-1.9.8-12.fc18.x86_64
pulseaudio-2.1-4.fc18.x86_64

Haven't got round to downgrade yet.

I'm beginning to wonder if this isn't a bug in QJackctl. It seems to have difficulty remembering which devices are selected (especially in bridging mode, where it seems to stick on same device for both while directly starting jackd works) and checking/unchecking the use dbus option then restarting the application equally seems to not necessarily change whether dbus is used or not.
Would it be easier if I took this upstream?

I am away from my computer for a few days, but when I looked at this before I left, it seemd to me that this version of jack was always runnung with verbose messages on which is a manifestation of bug 827748. This could also explain why the dbus flag is not been honoured properly after changing it.

To be sure I'd grab a version of jack from koji (the one with optimizstion turned off) 1.9.8-11 i think

I'll chase this with upstream, downgrading to the -11 build didn't really change the behaviour.

After checking with QjackCtl and Jack mailing lists it looks like it's a problem with pulse,
http://lists.freedesktop.org/archives/pulseaudio-discuss/2012-November/015190.html

The different devices problem is a different issue with jackdbus, apparently fixed in git, but less serious anyway. Have a good break.

OK, I can recreate this and I can suggest a workaround.

It seems that the module-esound-protocol is loaded be default. It takes a lock on the device (see ls /tmp.esd*) which seems to stop it from allowing pusle to release the device.

Commenting out this module in /etc/pulse/default.pa seems to fix for me.

I would strongly recommend that this legacy moudle is NOT loaded by default. I've responded to numerous issues where this has caused problems (for example /tmp/.esd1000 hanging around preventing pulse from restarting)

As for the dbus switch in qjackctl, you must shut it down and restart it for it to take affect.

Thanks, I'll try that. Have mailed the pulseaudio list about the issue and will add this information there once I've tried it out:
http://lists.freedesktop.org/archives/pulseaudio-discuss/2012-November/015190.html

I can confirm the always-on-verbose output in Jack 1.9.8-12 isn't present in 1.9.8-11. It seems to cause Jack to crash in a VM, likely because it just can't keep up (I doubt anyone would run Jack in a VM except for testing purposes anyway).

Will feed this all back into the Jam spin once I've got the wrinkles ironed out, it started as me checking to see how the Jack setup should work before updating the guide for it...

So I'm running into the same issue that Ian is having.

If I start a new user session by logging into F18 and cause a sound (for example, terminal bell by hitting backspace), I can no longer fire up qjackctl and have it get a session with dbus.

Killing pulseaudio and restarting (as my own user) has no effect.

Looking at my /etc/pulse/default.pa:

.ifexists module-esound-protocol-unix.so
load-module module-esound-protocol-unix

If I comment out these two lines and kill/restart pulse, it actually doesn't work at all -- I get no sound, period.

alsa-plugins-pulseaudio.i686 1.0.26-2.fc18
alsa-plugins-pulseaudio.x86_64 1.0.26-2.fc18
jack-audio-connection-kit.x86_64 1.9.9.5-1.fc18
jack-audio-connection-kit-dbus.x86_64 1.9.9.5-1.fc18
jack-audio-connection-kit-example-clients.x86_64 1.9.9.5-1.fc18
pulseaudio.x86_64 2.1-6.fc18
pulseaudio-gdm-hooks.x86_64 2.1-6.fc18          
pulseaudio-libs.i686 2.1-6.fc18
pulseaudio-libs.x86_64 2.1-6.fc18       
pulseaudio-libs-glib2.x86_64 2.1-6.fc18     
pulseaudio-module-bluetooth.x86_64 2.1-6.fc18
pulseaudio-module-x11.x86_64 2.1-6.fc18
pulseaudio-utils.x86_64 2.1-6.fc18
qjackctl.x86_64 0.3.10-1.fc18
wine-pulseaudio.i686 1.5.29-1.fc18            
wine-pulseaudio.x86_64 1.5.29-1.fc18

This was fixed upstream in January 2013, however only in trunk,
http://lists.freedesktop.org/archives/pulseaudio-discuss/2013-February/016054.html

I think that pulse 3.0 included in F19 fixes this. My workaround in F18 and earlier has been to add "pulseaudio -k" to "execute script on startup" in the QJackCtl setup|options menu. The problem with killing and restarting pulseaudio is that it can get back into the state where the device is reserved before pulse starts, doing it through the QJackCtl setup means there's no (or much less) pause.

It may be worth trying this command if Jack refuses to start:
dbus-send --type=method_call --session --print-reply --dest=org.freedesktop.ReserveDevice1.Audio0  /org/freedesktop/ReserveDevice1 org.freedesktop.DBus.Introspectable.Introspect
That should tell you if pulse has taken the address or not.

Jack in F18 by default doesn't really get a session by dbus (the jack dbus server is something slightly different), all it does is check on dbus to see if the device has been reserved and attempts to request it if it has.

I never really saw the problems coming from the esound module, not sure why it would disable sound for you. I've got it enabled here in F18. Last note, unless you have autospawn disabled for PA it shouldn't be necessary to manually restart after killing it. (If you wanted complete control of the sequence of PA/Jack initialisation it should be possible to disable autospawn and start PA through 'execute script after startup')

I'm going to do a fresh F18 install at some point and attempt some of this again to make sure it's consistent.  I was able to get some success with qjackctl by following these instructions:

https://docs.fedoraproject.org/en-US/Fedora/18/html/Musicians_Guide/sect-Musicians_Guide-Integrating_PulseAudio_with_JACK.html

I'll have to really dig to try to reproduce and document well.

This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.