On Wed, 24 Apr 2002, Maarten de Boer wrote:
> > > I was assuming that using poll (snd_pcm_wait), with the
> > > alsa-lib/test/latency.c program would have snd_pcm_read
> > > return period size samples at a time, but this is not
> > > the case.
> > > [..SNIP..]
>
> > It's intended. It looks better in my eyes, if we can process some data
> > ahead in low-latency application that wait for whole batch. Of course,
> > optimized applications for cpu-usage might work differently.
>
> I see... However, I can imagine many situations in which you are
> processing with a fixed buffer size (doing an fft for example).
> And I still think that it is reasonable to expect that the default
> behavious is that readbuf will always return the same amount of
> samples. Would it not be possible to add a commandline argument
> to specify the behaviour ?
>
> -p,--poll use poll (wait for event - reduces CPU usage)
> events are generated when a new period of frames is available
> -q,--quickpoll use poll (wait for event - reduces CPU usage)
> events are generated when new frames are available
>
> or something like that. As the user has to specify either one, he/she will
> be concient of what is happening.
>
> Apart from that, I think it is a bit agressive that the default execution
> of the latency test is non-blocking, which causes all CPU to go to the
> latency test, and at first sight really looks like your machine locks up.
> Would it be a good idea to make blocking the default, and change the
> argument
>
>
> -b,--block block mode
>
> for
> -n,--nonblock non-block mode
>
> ?
Feel free update the latency utility... I'm looking forward for any good
patches.
Jaroslav
-----
Jaroslav Kysela <[EMAIL PROTECTED]>
Linux Kernel Sound Maintainer
ALSA Project http://www.alsa-project.org
SuSE Linux http://www.suse.com
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
