[PD] pd-0.45 + jack == weirdness

[batinste]

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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130626/d4ea61a1/attachment.htm>