[PD-dev] jack dbus?

IOhannes m zmoelnig zmoelnig at iem.at
Tue May 28 09:26:21 CEST 2013

Hash: SHA1

On 2013-05-28 07:08, Jonathan Wilkes wrote:
> Ok, quick restatement of the problem:
> How does one get Pd to just run in GNU/Linux for casual/sporadic
> use cases? Like 1 fire up Pd to patch an idea with Firefox/music
> player/other stuff sitting in the background 2 audio from online
> tutorial while patching in Pd with audio 3 some dude screwing
> around in Ubuntu with it, learns enough to get interested in fairly
> low latency to process some guitar sounds, possibly live
> Cases 1 and 2 could benefit from having a PulseAudio backend in Pd,
> but case 3 would still be a pain because at the point that the
> guitarist cares about latency he/she is back to screwing around
> with audio settings (either directly through ALSA or with JACK).
> (If I'm wrong and Pulse can cover use case 3 I'd like to hear about
> it, but from what I've read Pulse is not designed with realtime
> audio processing as a goal.)

what works for me so far is:
- - run jack as the native backend on my desktop (jackd gets autostarted
at login, and is running throughout my session)
- -- obviously Pd will always use the jack backend
- - run pulseaudio *on top of jack*.
- -- thus any pulseaudio-aware application (like firefox) can simply
play back
- -- i can route pulseaudio-apps into Pd (not that i ever needed this
"in real life")

i really think that this is the way to go: have any consumer-framework
sit on top of a "pro" framework, rather than the other way around
(e.g. have pulseaudio provide a virtual alsa-device)

setting up was pretty easy by installing the "pulseaudio-module-jack"
(on debian),and uninstalling all the other pa backends.

> So, I'm curious about this: 
> http://trac.jackaudio.org/wiki/JackDbusPackaging
> Specifically the "D-bus only JACK" route.  _If_ it works reliably
> (and of course that's a big if) then it gives the best of both
> worlds: all cases 1,2, and 3 above are covered by the JACK server
> automatically starting and Pulse getting out of the way for it.
> Moreover, Pulse clients get routed to JACK with what I take are
> "sane" defaults.  So, if you have Pd running through JACK with this
> setup and then you open up a youtube video in Firefox, Pulse will
> automagically make a connection to JACK for it and (I'm guessing)
> hook it up to the output.
> Any thoughts on this?

personally i would prefer to *not* pull in additional dependencies if
possible. afair, d-bus is notorious for pulling in an entire desktop

one of the problems of Pd i see is, that all the audio backends are
linked into the main binary. so if you have a binary with jack/dbus
support, you *must* install jack/dbus or you will not be able to use
Pd at all (even if you don't care for audio at all).

> I'm thinking if we could build up a body of knowledge on this
> approach it would be the easiest way to get worry-free audio setups
> with GNU/Linux distros that wouldn't give new users headaches.
> Plus it would scale up: if they learn and care about insanely low
> latencies, they are already using JACK so it's just a matter of
> firing up qjackctl or whatever and configuring the audio server
> they've been using.

from a technical perspective, i think that the way to go is to support
as many (pro and consumer) audio backends as possible, but always make
this a runtime-choice (that is: make audio backend support in Pd a
loadable mechanism)


Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/


More information about the Pd-dev mailing list