Subject: Re: [ecasound] Strange ecasound behavior
From: Dubphil (dubphil_AT_free.fr)
Date: Sat Dec 04 2004 - 01:57:36 EET
> Hello,
>
> I'll cc this to jackit-devel as I suspect this could be a libjack
> problem.
>
> On Fri, 3 Dec 2004, Dubphil wrote:
>> I run ecasound like this :
>>
>> ecasound -a:1,2,3,4 -i jack /
>> -a:1 -efl:300 -o jack /
>> -a:2 -efb:500,400 -o jack /
>> -a:3 -efb:1000,600 -o jack /
>> -a:4 -efh:1300 -o jack
>>
>> thanks to qjackctl, I route TerminatorX to the ecasound input,
>> and I route the 4 ecasound outputs to ardour.
>>
>> Everything goes well as long as, i suspect, an audio
>> signal is received by ecasound. When the sample stop in TerminatorX,
>> jack is struggling with xruns and if I don't play another sample in
>> a short time, ardour disconnect from Jack and everything crash !
>> This behaviour hapens both with the DeMuDi and AudioSlack distros.
>
> Ok, and based on your later message, replacing TerminatorX with QSynth
> gives similar results, so it's not a TerminatorX problem.
>
> And Ecasound gets zombified when this happens.
>
> Anyway, I suspect that this is a problem in libjack. What essentially
> happens is that...
>
> - you setup a subchain jackd->terX->ecasound->ardour->jackd
> - terX quits
> - jackd needs to reorganize the subchains so that jackd->ecasound
> starts the updated chain
> - ... but jackd produces lots of xruns and ecasound is zombified
>
> I can think of two possible explanations:
>
> 1) race between terX disconnect and jackd engine cycle
> - jackd tries to call terX after terX has exited
> - there will be no answer to wake_next and ecasound
> will also be in the process zombified
>
> 2) a bug in libjack
> - could the below code in client.c cause trouble...?
>
> if (client->upstream_is_jackd) {
> DEBUG ("WE DIE\n");
> goto zombie;
> }
>
> You could compile JACK with --enable-debug and try to see
> whether "WE DIE" is printed to ecasound's console.
>
> Also, try running jackd with a long timeout (-t 5000) and enable
> ALSA driver's safe-mode (--softmode jackd param after -d alsa).
>
>> The lonely trick I've found is to permanently connect my capture
>> channel output to the ecasound input :-( but I need this channel in
>> order to connect my TB303 and I don't want it to be processed by
>> ecasound.
>
> Hmm, this also suggests that the bug is in libjack as adding the dummy
> connection changes the graph topology (there is no direct terX->ecasound
> link and thus you get different behaviour in the case when terX exits).
>
> Anyways, it's been a while since I last played with JACK internals, so I
> might be completely wrong here... :)
>
> PS The jackd(1) magpage says that -t xxx argument is time in microseconds
> but the code seems to interpret it as milliseconds...?
>
> --
> http://www.eca.cx
> Audio software for Linux!
>
> --
> To unsubscribe send message 'unsubscribe' in the body of the
> message to <ecasound-list-request_AT_wakkanet.fi>.
>
>
sorry but TerminatorX doesn't exit, it is always there and his connection
with jack is always working because if I don't connect the capture ports,
and if I play another sample the xruns stop and the sample plays.
thanks.
Philippe
This archive was generated by hypermail 2b28 : Sat Dec 04 2004 - 00:55:29 EET