Subject: Re: [ecasound] A question, a weird problem and a bug
From: S. Massy (theanaloguekid@tak.net.dhis.org)
Date: Mon Apr 30 2001 - 18:02:30 EEST
On Mon, 16 Apr 2001, Kai Vehmanen wrote:
> On Wed, 21 Mar 2001, S. Massy wrote:
>
> > 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
>
> Did you have double-buffering mode enabled? When -z:db
> is enabled, disk thread wakes up once in a while, runs
> at full disk speed to fill up the buffers, and then
> returns back to sleep.
Hmm, Has there been any tweaking done to the engine's code during the past
two weeks? The behaviour I described now seems to be gone, the CPU power in
use now remains stable. The command I use is:
# ecasound -z:nointbuf -r -i:alsa,sbl -o:alsa,sbl -c
(default-to-double-buffering = false)
>
> > 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?
>
> Huh, beats me. :) I'd bet my money on a kernel-related
> latency problem.
Yes, that's possible... I should give the low-latency patches another try...
Well, that's not a big problem, still, that's a bit surprising when you type
ps and get an xrun automagically.
>
> > 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?
>
> It should restart ALSA devices properly after an xrun. Oh well, I'll
> check the related ecasound code once ALSA 0.9.x API documentation gets
> ready.
That's actually a bit annoying; sometimes there's just a very short xrun
that wouldn't really be audible but now I have to stop and restart the
processing every time a xrun occurs...
>
> --
> http://www.eca.cx
> Audio software for Linux!
>
>
> --
> To unsubscribe send message 'unsubscribe' in the body of the
> message to <ecasound-list-request@wakkanet.fi>.
>
-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request@wakkanet.fi>.
This archive was generated by hypermail 2b28 : Mon Apr 30 2001 - 18:11:55 EEST