Re: [LAD] two reasons for jack2 .. and the problems with it.

Well I did the switch: jackd here is now jackdmp.. and [almost] everything works just like before. The motivation for this was to benefit from the re-loadable backend feature of jackdmp for two reasons: - to be able to quickly switch between internal and external soundcards - have JACK sessions survive suspend/resume cycles (using dummy backend) After some initial testing I was quite enthusiastic. It looks very smooth on the surface. but - or course - the devil is in the details: Calling `jack_control sm` drops existing connections to system:* ports. OK. They may be different but here they're not. no problem: this can be remedied with a simple shell script. But worse: both patchage (v0.4.4) & qjackctl (v0.3.6.22) go haywire (either 100% CPU usage, disconnect or crash) when replacing the back-end while they're running. I have not yet found a pattern in the app's behaviour.

Qjackctl's issue can be worked around by stopping it before doing the switch: 'dbus-send --system /org/rncbc/qjackctl org.rncbc.qjackctl.stop' but re-starting it after the switch fails if the qjackctl setup does not match the current active hardware (it tries to start a 2nd jackd instead); otherwise it works just fine. ardour2 disconnects if I switch directly between two alsa backends. however going alsa,hw:0 -> dummy -> alsa,hw:1 works. Clearly there's some issue remaining to be worked out. The good news: both mplayer and alsa-plug have no problem with me changing the jackd-backend (while retaining sample-rate and buffersize) even while they're playing; so I'm good most of the time :) The scripts I use are available at http://rg42.org/wiki/jack2contol Has anyone else ventured down that road and has a similar setup running? Can someone reproduce these problems? Cheers! robin