Subject: [ecasound] A question, a weird problem and a bug
From: S. Massy (theanaloguekid@tak.net.dhis.org)
Date: Thu Mar 22 2001 - 04:29:01 EET
The question:
I did some monitoring while ecasound was doing some real-time
processing because I was eager to find out where possible clashes
could occur and also just how tiresome it might be for my cpu. I was
a bit surprised to find out that the amount of cpu power in use varied
greatly whereas it remains relatively stable for normal operations
(simple playback for example). Actually it follows a very constant pattern
where the amount of cpu time in use climbs steadily before falling
back. I don't have the exact intermediate values but it always seem to
reach up to 25% of the cpu as its max value and 0.1% as its
lowest. The cycle is always about a minute long. The command I use for
real-time processing is usually (and was during this monitoring):
ecasound -r -z:nointbuf -sr:48000 -f:16,2,48000 -i:alsa,sbl -o:alsa,sbl -c
I'd be happy if anyone took the time to explain why there is such a
great variance in the cpu power in use, it sort of awoke my curiosity.
The weirdness:
Now this is the weirdest thing I've ever seen. Still while running the
same instance of ecasound I discussed above (well it was the same
command anyway) I found out that issuing ps in another console
triggered an xrun. (All other commands mentioned were run as a normal
user while ecasound was, of course, running with superuser
privileges.) So I said to myself, "hah! this must be an xrun
resulting from some latency created when reading on the proc
filesystem!" So I dug around for a latency test-suite that was lying
around on my hd and found out what they were using for testing latency
created through /proc (which is top -d 0.01) Well, I ran top updating
its info from /proc every hundredth of a second for five minutes (it
was also using up to 70% of the cpu power) and ecasound remained rock
solid, no xrun. Then I just exited top and typed "ps" and BANG, xrun!
Anyone having a possible explanation for this? I realize it is most
likely related to alsa, still, it seems weird, doesn't it?
The bug:
Finally I noticed that whenever an xrun occurs and alsa device is used
for playback, the playback does not resume and the following is
printed:
ALSA lib pcm_hw.c:254:(snd_pcm_hw_start) SNDRV_PCM_IOCTL_START failed:File descriptor in bad state
The processing continues but what is sent to that particular device is
not heard. I have to issue a "stop" then "start" for the device to be
properly initialized once again. As I understand it, when encountering
an xrun and in -z:noxruns mode, ecasound stops and restart in an
attempt to get everything back into sync. Is it possible that there's
a bug in the code supposed to reinitialize the alsa device performing
playback?
Regards,
S. Massy
-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request@wakkanet.fi>.
This archive was generated by hypermail 2b28 : Thu Mar 22 2001 - 04:33:47 EET