Description of problem: Can't start jackdbus (formerly know as jackdmp) with a d-bus signal, by default. Version-Release number of selected component (if applicable): jack-audio-connection-kit-1.9.7-1.fc15.src.rpm jack-audio-connection-kit-1.9.7-2.fc15.src.rpm How reproducible: Ever Steps to Reproduce: 1. Install jack-audio-connection-kit 2. Try to launch it with d-bus Actual results: Nothing Expected results: Jackd launched Additional infos: -> org.jackaudio.service : Exec=/usr/bin/jackdbus auto And spec order to construct the two versions (--classic and --dbus) -> But jackdbus (and jack_control) are excluded from rpm. Solution : Remove %exclude %{_bindir}/{jackdus,jack_control} from spec.
Created attachment 505644 [details] removing %exclude for jackdbus and jack_control binaries
Fernando, Do you remember why we excluded the jackdbus and jack_control binaries from our RPMs? I remember that this is what you advised because these two binaries confused some users, but I don't remember the true story. muny, Meanwhile could you tell us why you need these two binaries?
(In reply to comment #2) > Fernando, > > Do you remember why we excluded the jackdbus and jack_control binaries from our > RPMs? I remember that this is what you advised because these two binaries > confused some users, but I don't remember the true story. Hmmm, my memory is a bit fuzzy, I would have to look at my old emails. ... This is what I found, there were other threads but this is the first one that pops out in a cursory search. I imagine the situation is now different, for example I think that qjackctl now includes dbus support so it maybe time to try it out - carefully :-) Dbus support is partially compiled in because we need the communication between jackd and pulse audio for sound card reservation. The compilation is done in "clasic" mode for backwards compatibility so maybe not all the dbus code is included? I have to check more carefully what each option means.... -------- Original Message -------- Subject: Re: [PlanetCCRMA] dbus support for jack? Date: Sun, 22 Nov 2009 15:41:51 -0800 From: Fernando Lopez-Lezcano <nando.EDU> CC: planetccrma.EDU On Sun, 2009-11-22 at 09:16 -0800, Er wrote: > Hi! > > I've just discovered a brand new software called Ladish (http://ladish.org/) > which aim to save and restore jack session. I don't have to explain you how > helpful it is when you have to start always the same 5 application to make > your music. > > Anyway, > > That software needs the dbus support to be enable in jack, so here's a > few questions : > > 1) Is there any reason why it's not set as default? In part because it is not settled how dbus support is going to be enabled inside jack itself. Currently dbus support is not included in the jack source. The current implementation is a separately patched jack released by Nedko Arnaudov. See the latest post from him (where maybe you found out about ladi): http://lalists.stanford.edu/lad/2009/11/0310.html and the response in the thread from Paul Davis as to why things are in the state they are (not as the result of generalized hatred of dbus, as the thread would lead you to believe): http://lalists.stanford.edu/lad/2009/11/0318.html (there were many threads before on this very same subject). Dbus support inside jack as currently implemented makes jakc behave differently and you can't choose at runtime whether to enable it or not, it is something you compile in or not. I made the mistake of enabling dbus in jack and it caused problems for users. I had not realized that the _behavior_ of jack had actually changed in a non compatible way - you can't do that and not give the option of opting in and out to users, that is impossible with the current implementation. > 2) I didn't found the srpm so I can make it myself, are they available > somewhere? All srpms for my packages are available in the Planet CCRMA web site, for example for fc11: http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetccrma/11/SRPMS/ (substitute other release numbers for previous or later versions) The spec file has support for dbus in the form of a macro you define or not. So it should be easy to roll your own (but I have not checked it still works for some time and you would need to download the latest Nedko tarball). If it turns out it is possible to use alternatives to enable the peaceful coexistence of jack1 and jack2, then the same trick might be used to also add jackdbus to the mix (as a testing ground). That would be neat if it is never enabled by default. > I really think this ladish can really improve our user experience, > I hope it'll evolve quickly! Something like LADI is really really needed. Improved user experience was the promise of lash before ladi, and ladcca before lash (look them up :-) One of the problems is that application writers have to include support for it in their applications and you get a typical chicken and egg problem (which one was first?) -- Fernando ---------
jack-audio-connection-kit-1.9.8-2.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/jack-audio-connection-kit-1.9.8-2.fc16
Package jack-audio-connection-kit-1.9.8-2.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing jack-audio-connection-kit-1.9.8-2.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-17454/jack-audio-connection-kit-1.9.8-2.fc16 then log in and leave karma (feedback).
I am still coming to terms with how jackdbus is supposed to fit in with my particular setup. I have been looking at this page: http://trac.jackaudio.org/wiki/JackDbusPackaging In the interests of allowing users to determine which of the three presented methods are used can I suggest moving jackdbus into a separate sub-package? Sorry if I'm being a bit vague, I'm still working through testing this.
I have been thinking about doing that. What regression did you experience by having the jackdbus executable in the main package?
To be honest I'm not exactly sure what's going on. Sometimes pulseaudio is not releasing the sound card and jack won't start (from qjackctl with dbus enabled). Sometimes I am getting "D-BUS: SetParameterValue('driver:outchannels', '2'): Parameter value type mismatch: was expecting 'i', got 'u'. (org.jackaudio.Error.InvalidArgs)" but jack starts OK. Other times it fails We have three players here, jack, pulseaudio and qjackctl. I'm trying to determine the culprit and to ensure that my settings are being passed correctly from qjackctl via the dbus interface. I'm happy to continue testing this and hopefully I should have something more concrete.
(In reply to comment #7) > I have been thinking about doing that. What regression did you experience by > having the jackdbus executable in the main package? I would probably do a separate package. I don't think there is an awareness of how things change when full dbus support is included. A separate package enables only users that know to install and use it. Or maybe a user that knows all about it could write a nice web page or README file...
Yeah I agree. I'm happy to put something down in the readme when I finally work out what's going on. All I'm confident about is that prior to jackdbus being available the manual methods of suspending pulseaudio were successful in giving up the sound card. There is some confusion out in userland as qjackctl has been compiled with DBUS support but until now jackdbus was not around to act on it. There is one open ticket in qjackctl trac (potential fix in SVN only at this stage) which might explain the "D-BUS: SetParameterValue" errors above. More later.
If I disable all pre/post startup scripts relating to pulse, enable qjackctl to use the dbus-interface, I can start up and shutdown at will ok, and all is reasonably stable apart from a few more detectable xruns. Pulseaudio gives up the HW resource OK although I still get the above DBUS parameter errors. The calf plugins (svn/unreleased in Fedora) which worked flawlessly before no longer do under qtractor. CALF DEBUG: instance 0x5823fa0 data 0x57e4990 CALF DEBUG: calf 0x31b9eb12c0 cpi 0x31b94fcaa0 terminate called after throwing an instance of 'calf_utils::config_exception' what(): Configuration server couldn't be contacted: D-BUS error: The GConf daemon is currently shutting down. ** (qtractor:7342): WARNING **: The GUI exited before establishing contact with the host Look, I'm going to move this discussion upstream, I'll start with Rui first, then Nedko and perhaps they can fill in some of the blanks. I'll report back here so leave this open if you could. In the meantime, lets move this into a separate package (actually upstream recommend this here: http://trac.jackaudio.org/wiki/SuggestedPackagingApproach)
Package jack-audio-connection-kit-1.9.8-3.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing jack-audio-connection-kit-1.9.8-3.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-17454/jack-audio-connection-kit-1.9.8-3.fc16 then log in and leave karma (feedback).
jack-audio-connection-kit-1.9.8-3.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.