[LAU] jackdbus issues: a workaround ? (Was: more jack/qjackctl madness)

[alex stone]

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 at marcochapeau.org> wrote:
> On Mon, 18 May 2009 01:50:45 +0200, Fons Adriaensen <fons at kokkinizita.net>
> 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 at lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
>



-- 
Parchment Studios (It started as a joke...)