Re: [ecasound] Strange ecasound behavior

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [ecasound] Strange ecasound behavior
From: Dubphil (
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...?
> --
> Audio software for Linux!
> --
> To unsubscribe send message 'unsubscribe' in the body of the
> message to <>.

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.



New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sat Dec 04 2004 - 00:55:29 EET