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


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