Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0

[Bill Huey]

On Sun, Jan 28, 2001 at 06:14:28AM -0700, [e-mail] wrote:
> > Yes, I most emphatically do disagree with Victor!  IRIX is used for
> > mission-critical audio applications - recording as well playback - and
> And it has bloat, it's famously buggy, it is impossible to maintain, ...

However, that doesn't fault its concepts and its original goals. This
kind stuff is often more of an implementation and bad abstraction issue than
about faulty design and end goals.

> > used.  I will be very happy when Linux is as good in all these areas,
> > and I'm working hard to achieve this goal with negligible impact on the
> > current Linux "sweet-spot" applications such as web serving.
> As stated previously: I think this is a proven improbability and I have
> not seen any code or designs from you to show otherwise.

Andrew Morton's patch uses < 10 rescheduling points (maybe less from memory)
and in controlled, focused and logical places. It's certainly not a unmaintainable
mammoth unlike previous attempts, since Riel (many thanks) has massively
cleaned up the VM layer by using more reasonable algorithms, etc...

> I suggest that you get your hearing checked. I'm fully in favor of sensible
> low latency Linux. I believe however that low latency  in Linux will
> 	A. be "soft realtime", close to deadline most of the time.

Which is very good and maintainable with Andrew's patches.

> 	B. millisecond level on present hardware

Also very good an useable for many applications short of writting dedicated
code on specialized DSP cards.

> 	C. Best implemented by careful algorithm design instead of 
> 	"stuff the kernel with resched points" and hope for the best.

Algorithms ? which ones ? VM layer, scheduler ?  It seems there's enough
there in the Linux kernel to start doing interesting stuff, assuming that
there's a large enough media crowd willing to do the userspace programming.

> > for low-latency tasks.  RTLinux is not Linux, it is a separate
> > environment with a separate, limited set of APIs.  You can't run XMMS,
> > or any other existing Linux audio app in RTLinux.  I want a low-latency
> > Linux, not just another RTOS living parasitically alongside Linux.
 
> Nice marketing line, but it is not working code.

Mean what ? How does that response answer his criticism ?

bill