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: Kai Vehmanen (
Date: Fri Dec 03 2004 - 23:50:24 EET

I'll cc this to jackit-devel as I suspect this could be a libjack

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!

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

This archive was generated by hypermail 2b28 : Fri Dec 03 2004 - 23:50:32 EET