I guess that asking Ardour's main dev
(Paul Davis, also one of jackd's devs) about the expected
behaviour of a jack app would be a good idea.
While Ardour without audio is pretty useless (not so true anymore
since it does midi now, but well), Pd is not, so my take on this
is "don't do anything i didn't told you to" :
I didn't specified -jack : don't start it, don't connect to it.
Let me handle this.
I didn't specified any audio options : don't do anything, i'll
start the whole mess.
Here is what i get when starting Pd-extended 0.43.4 and jackd
1.9.10 on ubuntu 13.04 :
~$ pd-extended
priority 6 scheduling enabled.
priority 8 scheduling enabled.
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jackdbus should be auto-executed by D-Bus message bus daemon.
If you want to run it manually anyway, specify "auto" as only
parameter
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
watchdog: signaling pd...
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
4 seconds trying to get that there's no jackd running... Did i
specified -jack ? No ! So why is Pd-ext trying to start it ?
On 26/06/2013 08:07, IOhannes zmölnig wrote:
On 06/25/2013 01:24 PM, Lorenzo Sutton wrote:
On 24/06/2013 18:58, Miller Puckette wrote:
Thanks... I'm toying with a middle solution, which would be simply to
open
jack with the JackNoStartServer option (one of JackOpenOptions).
I think this is a good idea anyway as the user might want to specify
jack options and it seems wrong to have Pd get involved in that.
hmm, i'm not entirely convinced about that: the autostarted jack server
should use sane defaults as configured by the user.
if these defaults are not what the user wants, they can always start the
jack server beforehand, and Pd will connect to that server.
in any case, i'd like to check with the jack-devs what's the *expected*
behaviour of a jack application...i'd really like Pd to behave as
"standard" as possible.
and of course the fact that Pd hangs on quit when it has an autostarted
jackd, is a bug. if the only way to fix this, is to prevent Pd from
starting jackd, then we might go that route. if we can make Pd quit
successfully even with an autostarted jackd, i'd like to keep the
autostarting.
what i'd like to have is, that Pd and jack are totally independent
processes: Pd should keep working (including quitting!), whether jack is
(auto)started or not, and it should gracefully survive a
shutdown/restart of the jack server. and the other way round.
I liked it when (v 0.42?) Pd would use jack if it found a jack server
running and just alsa otherwise...
honestly, i think this is too much intelligence on the Pd layer.
if the user chose "jack" as backend, then they should get "jack", and
not "alsa" or "asio". if there is no "jack" (and we cannot autostart),
then Pd should NOT try to grab the first available alsa device,
preventing any jack server from being started afterwards, and
potentially crashing the "700 gigawatt PA"* where Pd was never meant to
be routed to.
fgmasdr
IOhannes
* courtesy erik de castro lopo
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list