Re: [ecasound] Re: Bug#317900: ecasound freezes the computer under root with double buffering

From: Skliarouk Arieh <arieh@email-addr-hidden>
Date: Thu Jul 14 2005 - 14:36:36 EEST


> - which version of ecasound? (if old 2.0.x release, please upgrade

ecasound of version 2.4.1-1.

> - which soundcard...? the problem description sounds like a driver

The problem is 100% reproduceable on following two cards
Card: SiS SI7012
Chip: Analog Devices AD1980

Card: SiS SI7012
Card: Realtek ALC655 rev 0

Well, I suspected that the problem is in realtime somewhere. I really
need all these 15seconds of buffer, and highest possible priority (as
not to lose even single tick of audio).

Close the bug, as workaround that I found works for me, and I see that
not many are bited by the bug.

Thanks for spending time on the bug!


Kai Vehmanen wrote:

> Hello all,
> On Wed, 13 Jul 2005, Junichi Uekawa wrote:
>> It sounds possible, considering the privilege it is running under,
>> but nasty.
> [...]
>>> If ecasound runs with double buffering and under root, almost any kind
>>> of termination of the process causes complete computer freeze:
>>> /usr/bin/ecasound -b:4096 -z:db,661500 -r:99 -f:16,2,44100,i -i
>>> alsahw,0,0 -o stdout
> couple of notes:
> - -r:99 is very extreme and dangerous, please use the default "-r"
> or just a lower value like "-r:40"
> - -z:db,661500 is a _lot_ of buffering (15secs of audio at 44.1kHz),
> but might be needed on some machines
> And then a couple of questions:
> - which version of ecasound? (if old 2.0.x release, please upgrade
> to newer 2.2 (in sarge) and retry the tests, 2.0.x is really old
> and not supported anymore)
> - which soundcard...? the problem description sounds like a driver
> problem (running with -r, i.e. SCHED_FIFO scheduling, can turn
> a minor driver bug into a system-freeze type of problem)
> I've tested the above configuration myself on multiple machines and no
> freezes so far, no matter what I try.
>>> It exits properly, if I stop it as follows:
>>> killall -STOP ecasound; killall -KILL ecasound
>>> Another way to stop ecasound safely is to run it with tee like this:
>>> /usr/bin/ecasound -b:4096 -z:db,661500 -r:99 -f:16,2,44100,i -i
>>> alsahw,0,0 -o stdout | tee audio.raw > /dev/null
> Hmm, this is interesting. The signal handling has been changed
> a few times since 2.0.x -- if you are running 2.0.x, that might
> explain the problem. Otherwise further investigation is definitely
> needed. The bad news is that tracking down SCHED_FIFO-triggere problems
> can be very difficult.. :(
>>> Looks like ecasound does not tolerate any signal when it is in system
>>> call (read kernel mode) of any kind.
> This should not be the case. The signal handler is designed to be
> real-time safe, and should be able to cleanly shutdown the engine in
> all possible cases. But, but, obviously something goes badly wrong in
> your case...

SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast.
Ecasound-list mailing list
Received on Fri Jul 15 12:15:04 2005

This archive was generated by hypermail 2.1.8 : Fri Jul 15 2005 - 12:15:05 EEST