From alsa-devel-owner@alsa.jcu.cz  Sat Feb 13 01:06:08 1999
Received: from v.gp.cs.cmu.edu (V.GP.CS.CMU.EDU [128.2.191.166])
	by marvin.jcu.cz (8.9.1a/8.9.1) with SMTP id BAA19595
	for <alsa-devel@alsa.jcu.cz>; Sat, 13 Feb 1999 01:04:03 +0100
Message-Id: <199902130004.BAA19595@marvin.jcu.cz>
Subject: Re: MIDI/PCM synchro
To: alsa-devel@alsa.jcu.cz
Date: Fri, 12 Feb 1999 19:03:52 -0500 (EST)
From: Eli Brandt <eli@v.gp.cs.cmu.edu>
In-Reply-To: <199902102138.QAA16652@havoc.gtf.org> from "Data" at Feb 10, 99 04:38:48 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

Data wrote:
> Welcome to the wonderful, hairy world of real-time on general-purpose PC
> hardware!

I just want to hammer on the point that it's not the hardware's
fault, except in special cases.  It's the software's fault.
It could be fixed.

> Err .. well, I don't know.  Keep in mind that the BeOS is one of the few that
> ever did that achieved any notoriety.  Hardly any of the other big OSes were 
> designed with us real-time weirdos in mind.  I hate to say it, but music and 
> such is a pretty small market compared to databases and word processors.

Linux doesn't do marketing research surveys.  Linux doesn't have to
follow in the footsteps of the big OSes.  Linux could get it right.
It's not even bleeding-edge: there are mainstream Unix flavors with
real-time as a design goal.

> You've mentioned a few other OSes and their relative real-time merits.  But 
> 'user-space timing' will never be as good as doing things in the kernel, 
> because people in userland just can't see interrupts quickly enough.

Plenty of RTOSes give timing guarantees in the microsecond range.
It's even possible to do a creditable job retrofitting an existing OS.
IBM put a lot of effort into tuning AIX's real-time, but they got good
results -- sub-millisecond timing, IIRC.  SGI may have gotten off
cheaper, since I think Irix only gives hard guarantees when the user
code is bound to a different processor than the OS is.

An OS which supports a Unix API can provide user-space timing good
enough for audio work.  It's a matter of design.  I'm not a kernel
hacker, but I imagine reworking Linux for SMP also got it a fair bit
more preemptability.  What's the bottleneck now -- scheduler policy?
priority inversion? an uninterruptable stretch somewhere?

>   So, if you want to get things done _really_ right, you have to join the 
> kernel.

That's what Microsoft is saying -- they call it WDM Streaming.  Code is
better off in user-land where it can't do so much damage.  Truism, I
know, so I guess my point is that you *don't* "have to join the kernel".

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

