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

[Robin Gareus]

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