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

On 06/07/2010 10:29 AM, Stéphane Letz wrote:
>
> Le 7 juin 2010 à 01:49, Robin Gareus a écrit :
>
>> 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.
>
> Any log to help finding if jack2 is the problem?

I don't think it is. jack2 continues to run & play just fine.

The only messages in ~/.log/jack/jackdbus.log are:

 ERROR: Failed to find port 'system:playback_1' to [dis]connect
 ERROR: Failed to find port 'system:playback_2' to [dis]connect

Maybe this is related to the way patchage/qjackctl handle port
connections?! They hit a NULL pointer and then either crash or end up in
some funny state..

However jack2/dbus live-locks if I don't switch it to the dummy
interface before suspending the machine. jack1 just exits and jackdmp
produces tens of thousands of
 ALSA: channel flush for playback failed (File descriptor in bad state)
 JackAudioDriver::ProcessAsync: read error, skip cycle

error message which probably explain the live-lock.
That is also weird, because I've started 'jackd -S' so why would I get
ProcessAsync. Maybe the '-S' option is not passed through to jackdbus?!
I'll investigate..

In some earlier experiments I've seen jack2 crash; I've attached the
log, but jackdmp is not compiled with --debug so I'm not sure if they're
helpful.

>>
>> 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
>
>
> Stéphane

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev