On Thu, 8 Nov 2001, Maarten de Boer wrote:
> Paul Davis wrote:
> > Ah, OK. yes, i suppose this might not be clear.
> > [...]
>
> But you made it completely clear now! Thank you very much, Paul.
>
> Paul Davis wrote also:
> > 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.
>
> And this is the source of all problems: I thought it was a good
> idea to use latency.c as a starting point. It would be nice if
> there would be a small low latency i/o with some processing
> (yes, that would be a more appropriate place for the filtersweep,
> wouldn't it?) example in the alsa-lib/test.
I don't agree with Paul that the latency.c test program is not a good
example for testing and showing the capture -> process -> play circle
required by some applications. It's very simple command-line application,
easy extensible, now showing also the standard poll/read/write scheme.
Anyway, all problems (for poll mechanism) seem to be in the Linux
scheduler / wrong drivers or VM manager / mentioned many times by me and
until all these time gaps (from the view of a RT task) will not be solved,
we can't do this audio processing in a reliable way without having at
least two CPUs.
Jaroslav
-----
Jaroslav Kysela <[EMAIL PROTECTED]>
SuSE Linux http://www.suse.com
ALSA project http://www.alsa-project.org
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
