Marc, I'd be interested in hearing about your results on this little test. I tried it, as you've suggested, and it worked initially. But as you rightly say, the dbus daemon is used, and this brought up another challenge. When the system is rebooted, the dbus tries to assume priority, and i found jack was already started when i tried to open an instance of jack, so we're already facing a challenge just to get warmed up. After inserting the command, it worked the first time, but subsequent command calls didn't when restarting Qjackctl, even though the jack_control command was still present in Qjackctl setup as a command to be run before jack startup. On the contrary, jack tried to start but got shutdown almost immediately, and i had to remove the command, and run jack_control stop several times before the server finally laid down and died. (A Linux Warrior to the last. Make sure your enemy is truly out of the picture.) I've STILL yet to hear an answer to my question though. Will the Jack team be continuing a completely non-dbus/pulse build for those who want more control over their audio environments, or are we to be enslaved to this new lack of choice for all eternity? (I'm sure the armour's going to get rusty before then.) What disturbs me more than anything about this is the seemingly enthusiastic freefall into a hybrid that seems to cater almost exclusively to a particular distro type, that of package install. I finally got enough smarts together, and installed Gentoo and Fluxbox as a working audio/midi environment for writing music, and i'd hate to think i'm still to be 'forced' to adopt a dbus/pulse baby eating hybrid, because Johnny Air Guitar wants to listen to pistols and flowers in a non jack server written app, while he's plagarising guitar licks. I'm using Jack1 now, the non infant muncher version, so i've escaped much of Fon's angst, but i'm still wondering what the jackserver future holds, given the current, what seems, relentless determination on the part of enthusiastic jack devs to 'persuade' us into the alternative. Humour to the fore as usual in these challenging times, but also an increasingly unsettled perspective on what seems like capable and skilled people trying to featurise something that isn't broken at all, to cater for devs and distros that choose to use yet another soundserver, instead of actively contributing to the fine server we already have. surely the old adage still hold true in this case. "If it ain't broke..." Alex. p.s. what does pulse/dbus do, that Jack can't, if the same relentless effort being put into the dbus/pulse hybrid, were put into maturing Jack even further? And what of the devs who refuse, are reluctant to, or don't see the advantages in writing Jack audio code, and plugins for their apps? I still don't understand how writing a pulse plugin is any harder than writing a jack audio plugin, or code. On Mon, May 18, 2009 at 1:12 PM, MarcO'Chapeau <marco@xxxxxxxxxxxxxxxx> wrote: > On Mon, 18 May 2009 01:50:45 +0200, Fons Adriaensen <fons@xxxxxxxxxxxxxxx> > wrote: > > Hi, > > Let's try to find an acceptable workaround until this is all sorted out. > >> 1. I accidentally start a jackified app without a server >> running. This autostarts the wrong jackd. Jackd seems to >> ignore ~/.jackdrc. >> >> 2. No problem, this jackd had the -T option, when I stop >> the application then the jackd is gone as well. >> >> Without dbus all is ok afterwards. But with dbus: >> >> 3. I start qjackctl. It immediately shows a running >> jackd (** there was none before, so running qjackctl >> started it **). This jackd is the 'wrong' one. > > Very strange indeed... I'll test that. > >> 4. Stopping and starting in qjackctl does not help, >> this always starts the 'wrong' one. Qjackctl's setup >> window still shows the 'right' one, but all settings >> there are ignored. >> >> 5. So it's now impossible to start the 'right' one >> from qjackctl. To revert to normal you have to kill >> a daemon created by the dbus stuff. > > There's something you could try. In qjackctl there's a way to launch some > commands prior to jack startup. Could you try to add "jack_control stop" to > it ? This should stop any running server started in the jackdbus way. Be > aware though that the jackdbus process will remain even if the jack server > is > stopped. If you want the jackdbus to exit cleanly, you can add > "jack_control exit" to the other command. This should also work for what > you do in (5.) and is more convenient than a kill -9. > > Of course, you also need to be aware that jack_control will use the dbus > interface to send those calls to jackdbus... It might as well eat your > babies :) > > Cheers, > Marc-Olivier Barre. > ------ > Participez au black-out anti-HADOPI : > http://www.laquadrature.net/fr/APPEL-HADOPI-blackout-du-net-francais > _______________________________________________ > Linux-audio-user mailing list > Linux-audio-user@xxxxxxxxxxxxxxxxxxxx > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user > -- Parchment Studios (It started as a joke...) _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
