Subject: Re: [linux-audio-dev] Re: minimum tick time
From: Josh Green (jgreen_AT_users.sourceforge.net)
Date: Thu Nov 08 2001 - 02:26:17 EET
On Wed, 2001-11-07 at 08:55, Paul Davis wrote:
> >I don't think so, but I am probably completely missing the point.
> >Let's start all over. I have a patched kernel, and I want to have
> >low latency. I use latest alsa (cvs), and I run the latency test.
> >(As you might have noticed, I submitted an filtersweep effect for
> >the latency test, which Jaroslav added to the CVS. Try it with -e)
>
> if i may so, this is absurd :)
>
> >- if I run in nonblock mode, it eats all CPU. Latency is excellent,
> > but it would be nice if I could do something else in the meantime,
> > for example run a GUI.
> > $ latency -m 128 -M 128
> >- if I run in block mode, i get XRUNs, even with larger bufsize
> > $ latency -e -b -m 256 -M 256
> >- if I run in poll mode, idem
> > $ latency -e -b -m 256 -M 256 -p
> >
> >Is this expected behaviour?
>
> i don't know if its properly written to measure these things at low
> latency settings. i don't have the recent source code for this, but
> the version i have doesn't have poll mode in it. the program isn't
> meant to test "low latency", its meant to test round-trip latency,
> which is related, but not the same.
>
> all i can tell you is that, as you probably know by know, my apps run
> just fine with latency settings down as low as period_frames = 64 at
> 48kHz (about 1.3msec per interrupt). admittedly, thats on a dual CPU
> system. but its basically fairly easy to get this performance out of
> any program that is engineered properly. latency.c is not the correct
> place to start such a program from, however. its a test tool, not a
> viable application.
>
> what are you trying to do?
>
> --p
I think I know the source of Maarten's question. In the
alsa-lib/test/latency.c the "readbuf" routine has the following code:
do {
r = snd_pcm_readi(handle, buf, len);
} while (r == -EAGAIN);
For the non-blocking case this would take up 100% of the CPU time. I
wrote about this before on the alsa-devel list. Since its running in
SCHED_RR it tends to not let anything else run while it does (i.e.
machine freezes, except for sound output). So I believe the question
Maarten is asking, is how do I program a low latency audio application
without hogging the CPU. I think the answer is poll. The reason I
believe he was asking about increasing the system timer interval, is the
assumption was that poll was limited to the interval of the system
timer. I don't believe this is the case though, but to be honest don't
really know how an application would get scheduled to wake up once ALSA
is ready to send/receive a chunk of audio.
Maarten, please let me know if my assumptions are wrong, I wouldn't want
to put words in your mouth :)
--
Josh Green
Smurf Sound Font Editor (http://smurf.sourceforge.net)
This archive was generated by hypermail 2b28 : Thu Nov 08 2001 - 02:22:24 EET