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