Hello,
> - 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!
-
Arieh
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. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-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