Subject: Re: [ecasound] Strange ecasound behavior
From: Kai Vehmanen (kvehmanen_AT_eca.cx)
Date: Fri Dec 03 2004 - 23:50:24 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!
This archive was generated by hypermail 2b28 : Fri Dec 03 2004 - 23:50:32 EET