ecasound bug, bad chainsetup or stupid user?

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

Subject: ecasound bug, bad chainsetup or stupid user?
From: Eric Dantan Rzewnicki (eric_AT_zhevny.com)
Date: Tue Dec 09 2003 - 08:50:42 EET


Two issues: (sorry this got kind of long)

1)
I'm having some trouble with a chainsetup (guitar_mix.ecs -- see
attached).
Everything worked fine until I added amplify effects like this:

-ea:0 -kos:1,0,175,0.01,0

to each chain. After adding those the session works as before and the
added effects work as expected with the volume of each input being
modulated by a slow sine wave. But, when the session gets to the end
there is a second or two of very loud noise just before the processing
finishes. The meters in envy24control go all the way up and stay there
for a second or two. The sound sounds like it might damage my monitors
(if not my ears). I added the -eal effect to see if that would limit it
somewhat, but it did not.

I run ecasound and jackd as root with jack started like so:
jackd -R -v -d alsa -d ice1712 -r 44100 -p 256

2)
Then in attempting to find out was going on I came across another issue.
I loaded the chainsetup in an interactive session:
ecasound -c -s:/home/eric/bin/guitar_mix.ecs

I typed "start" and everything started playing. Then I wanted to jump to
just before the end when the noise occurs, but accidentally went too far
with "fw 2800" (the chainsettup is limited to 907s). My machine locked
up -- no mouse, no keyboard, couldn't switch desktops, couldn't switch
out of X -- for 1-2 minutes. I was then kicked out of X to a console
login prompt. (I login to a tty and then do startx). X was killed along
with jackd and anything else started while in X. But, ecasound was
hanging around like this:
root 10509 0.0 68.3 663512 530400 ? TL 20:54 0:00 ecasound
-c -s:/home/eric/bin/guitar_mix/guitar_mix.ecs

I captured as much info on this process from /proc/10509/ as I could.
It's in the attached file ecasound_debug. strace showed nothing. I tried
to run gdb on it but failed to capture the output. It was in libpthread
somewhere.

I was able to repeat this lockup. The 2nd time things went as they did
the first time. But, when I logged in after getting kicked out of X I
was unable to get a gdb session going. They kept getting killed with Out
of Memory messages. Eventually I had to reboot because my bash sessions
and even my getty's and logins were getting killed with Out of Memory
messages.

After the reboot, the 3rd time, things again locked up, but this time
they locked up hard. I didn't get kicked back out to a tty, so I
rebooted.

A 4th time I tried running jackd and ecasound from virtual terminals
without starting X. This time I got better information. jackd was killed
and the ecasound session was terminated, but I still had my bash
sessions. I jotted down the ecasound messages. I'm sure I didn't get
them quite right, but, starting after my "fw 2800" they went something
like this (repetitions ommitted):

prefilling i/o buffers
using realtime-sched (SCHED_FIFO)
Out of Memory: killed process xxx ecasound
(ecasound-watchdog) WARNING ecasound_signal_handler entered, this should
_NOT_ happen!
Out of Memory: killed process xxx jackd
[controller/processing stopped (cond)]
VM: killing process ecasound
Aborted
Warning: DBC_ENSURE failed - "is_running() == false",
eca-control-base.cpp, 265.

ecasound was still in the process table, but this time there were 5
seperate threads. One thread had a large amount of memory locked as in
the first time this happened. I had to kill it before I could start gdb
on the others. They all showed the same backtrace. I don't know of a way
to capture gdb output without being in X so I wrote it down by hand.
It's in the attached ecasound_backtrace. I hope I got it right and that
it's useful.

Admittedly this is not a normal use situation. It seems like asking
ecasound to take 15 channels of audio 40+ minutes into the future
probably just overwhelmed my available RAM, or something. The 4 input
tracks are around 77M each and are read from /mnt/ramfs/guitar_mix/
where /mnt/ramfs is a tmpfs. I generate each of these files with a
script that combines 3 randomly chosen shorter files.

My configuration is below.

-Eric Rz.

PII 400
768MB PC100
6GB / /dev/hda2
60GB /mnt/audio/ /dev/hdc1
drives tuned
128MB swap /dev/hda1
M-Audio Delta-66 w/omni i/o

debian testing (sarge)
linux 2.4.22-box1-pell-1
alsa-1.0.0rc2
    ./configure --with-isapnp=no --with-sequencer=yes --with-oss=no \
    --with-cards=dummy,virmidi,serial-u16550,mpu401,ice1712,ymfpci
libsndfile-1.0.5
    from tar.gz. debian only had 1.0.4
jack-0.91.1
    ./configure --enable-optimize --with-default-tmpdir=/mnt/ramfs/
--disable-portaudio
ecasound-2.3.2
    ./configure --enable-pyecasound --disable-oss --disable-arts


guitar_mix.ecs


ecasound_debug


ecasound_backtrace


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

This archive was generated by hypermail 2b28 : Tue Dec 09 2003 - 08:46:01 EET