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@xxxxxxxxx> 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@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
