________________________________ From: IOhannes m zmoelnig zmoelnig@iem.at To: pd-dev@iem.at Sent: Tuesday, May 28, 2013 3:26 AM Subject: Re: [PD-dev] jack dbus?
-----BEGIN PGP SIGNED MESSAGE----- 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)
How do you configure jack to start at login?
- -- obviously Pd will always use the jack backend
- run pulseaudio *on top of jack*.
Yes, that is the way to go. And as far as I can tell, that's what PulseAudio is supposed to do when jack is started, whether it's by jack d-bus, at login, or manually starting 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.
Why is it necessary to uninstall those other 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 environment.
it does not depend on an entire desktop environment.
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 must be reading different documentation than you because AFAICT jack d-bus is a user-facing option for how to get JACK to interact with the system. Recommending it as the preferred way to connect doesn't require any backend coding.
But I'm not actually recommending it as the preferred way-- I still need to test it and compare it to the "classic" way of using JACK.
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)
That's a fine goal, as it would solve the problem about requiring JACK/ALSA dependencies even if the user doesn't want audio. But given a limited amount of time and money, the question is what is the easiest way to help new and old users avoid Linux Audio Hell? And I imagine that is currently either autostarting JACK at login or taking the JACK dbus route.
-Jonathan
fgamsdr IOhannes
_______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev