On Thu, 2001-11-08 at 01:52, Jaroslav Kysela wrote:
> 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
>
Having the latency.c test program take up 100% CPU doesn't seem all that
friendly though, or desirable for duplication in another application.
--
Josh Green
Smurf Sound Font Editor (http://smurf.sourceforge.net)
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
