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

Danni, and i'm sure you have a fine collection of headscarfs to
complete the 'picture'. :)

Thanks for the explanation about Dbus.
And for what it's worth, i think you've hit the nub of this (imho). If
app builders use jack by default, or have a jack option in audio and
midi preferences, we'd be discussing the weather instead.

Alex.

On Mon, May 18, 2009 at 6:37 PM, Danni Coy <danni.coy@email-addr-hidden> wrote:
>
>>
>> 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.
>
> Pulse and DBus are two completely different things....
>
> DBus is a means for two processes to communicate with each other. It is the
> standard way of communicating with running applications on GNOME and KDE 4
> Desktop environments. KDE 2/3 had a different IPC mechanism which was very
> similar.
>
> Though it is typically run in a desktop environment AFAIK it is not dependent
> on having a desktop. Using DBus for IPC is a bit like using XML to do your
> config files... You get to do the job using standard tools and libraries and end
> up maintaining less code.
>
> It also means that users and developers now have a standardised method of
> talking to your app/daemon while it is running. I am hoping this can go some
> ways to providing a LASH interface that works properly.
>
> Currently I don't see any long term downsides to using DBus as the IPC. The
> short term problems is that applications like qjackctl can't yet properly
> interact with a dbus based Jack and until that happens the old method should
> be the one that the distros use by default.
>
> Pulse on the other hand is a sound deamon that does seem to be taking over
> things. Mostly it provides a means of using different applications together on
> hardware that does not support hardware mixing. (something I would much rather
> see ALSA fixed properly to do. To me it is a reasonable idea in theory but a
> PITA in practice. Fortunately I have a FFADO soundcard which means that jack
> is the only supported means of communicating with the hardware. Since xinelib
> now supports jack - pretty much everything I want to use will work. You know
> for when I want to listen to Pistols and Flowers in Amarok and plagiarise
> guitar licks :p
>
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user@email-addr-hidden
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
>

-- 
Parchment Studios (It started as a joke...)
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user