Subject: [linux-audio-dev] linux real-time audio performance
From: est_AT_hyperreal.org
Date: to elo 19 1999 - 18:16:31 EDT
Erik de Castro Lopo discourseth:
> est_AT_hyperreal.org wrote:
> >
> > I've got IDE and UW SCSI here, and they give me equal performance
> > (even with my non-Intel chipset). If I want real-time, I find I need
> > to patch linux. :)
>
> Questions, so many questions :-).
>
> What application is this?
latencytest, oolaboola, rtcskips (a more q&d dropout test than
latencytest).
> Do you know if its using the standard realtime scheduler or
> rt-linux?
Standard POSIX real-time.
> Has anybody made a comparision of the performance of a standard process
> vs a realtime process (ie using sched_setscheduler) vs rt-linux vs
> linux kernel with patches?
I've done all of that..with various kernel versions and patches except
rtlinux. You can pretty much count on occasional dropouts >50ms on
stock linux. pre-2.2.8 is even worse. Using linux 2.2.10 and the
latest (non-public) patches this comes down to 3ms..and at that point
it starts to become processor rather than disk dependent so I should
say that that's on my amd k6-2/350.
rtlinux apparently can provide sample-level latency even while a stock
linux is doing wacky things (I have no reason to doubt David Olofson
on this). However, rtlinux has a completely different development
architecutre than POSIX (some commonality is emerging due to David's
efforts, but differences will remain). Also, as soon as a single
element of control goes through standard linux then control latency is
at the mercy of standard linux even if data latency is maintained by
rtlinux.
> Care to write a paper about it?
Well, these answers should be integrated into Paul Winkler's FAQ..and
people should keep asking questions. :)
The most urgent question to me is how we, as a community, can lobby
consistently and constructively for attaining and maintaining high
standards in this area.
Eric
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:52 EST