-----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) - -- 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 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'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) fgamsdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlGkXBgACgkQkX2Xpv6ydvRxOgCg7sHPrM2tsFzx3n9hKmxUquvY lcYAoOU+IvT1vEi8vQdexgI7Te4qIW/C =y+ic -----END PGP SIGNATURE----- _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
