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

Don't get me started about Ubuntu and jack support. It really is a second
class citizen - As it stands jack is not an officially supported package (It's
in Universe in Ubuntu speak)... Which means that if you want jack support for
any supported application you need to compile it yourself. I think a big part
of this is ignorance on the part of the packagers. I imagine that other
distros are similar.

Part of the problem is that Jack still takes considerable leg work to get up
and running properly. It's value may not be apparent to a new user and it is
different to how things are done on other platforms. Guaging from places like
the Ubuntu Forums and even things like Linux Audio Podcasts only a small
subset of users actually get a functional jackd setup working. I am not sure
how but it seems to me that the shortest path should be shortened.

On Tue, 19 May 2009 12:46:46 am alex stone wrote:
> 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

-- 
If it's worth hacking on well, it's worth hacking on for money.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user