From alsa-devel-owner@alsa.jcu.cz  Wed Feb 10 22:39:31 1999
Received: from havoc.gtf.org (IDENT:data@panic.ohr.gatech.edu [130.207.47.194])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id WAA07094
	for <alsa-devel@alsa.jcu.cz>; Wed, 10 Feb 1999 22:38:51 +0100
Received: (from data@localhost)
	by havoc.gtf.org (8.8.7/8.8.7) id QAA16652
	for alsa-devel@alsa.jcu.cz; Wed, 10 Feb 1999 16:38:48 -0500
From: Data <data@havoc.gtf.org>
Message-Id: <199902102138.QAA16652@havoc.gtf.org>
Subject: Re: MIDI/PCM synchro
To: alsa-devel@alsa.jcu.cz
Date: Wed, 10 Feb 1999 16:38:48 -0500 (EST)
In-Reply-To: <00a401be54e7$a44338c0$47010180@pcbg> from "Benjamin GOLINVAUX" at Feb 10, 99 12:22:27 pm
Content-Type: text
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

> 
> I'm fed up with these timing issues...

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

> Everytime one needs a good timer, things always end in putting the relevant
> code in kernel space.
> 
> Do you really think a modern operating system can't offer more options to
> programmers than putting their code in kernel space ?

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.
 
> you _all_ know that audio, midi, video, process control and even (to a minor
> extent) games BADLY need good timing performances.
> 
> Everyone seems to bother with Windows performance with real-time audio/video
> apps (my god ! how choppy that video is.... why can't it be better ? I used
> to watch Wing Commander video on my 486 !!!! Hey... that $1000 audio card...
> why can't I sync midi and audio ? I got a PII 450 !!!!!!!) but I don't think
> Linux is, from an architectural point of view, better (yes I know ALSA
> latency is very good... But is it useful since creating a process or
> accessing to disk can spoil this latency).

Ok .. well, read on.

> You know debugging kernel code is painful.... BeOS has adressed these issues
> by providing user space threads with good multimedia timing. SGI has also
> patched IRIX to reduce audio latency. And I'm afraid Windows won't be long
> before providing decent real-time _for multimedia_ (I'm not talking about
> process control s resolution for windows).
 
That's Microsloth's prerogative of course; although I doubt it would help 
their code to look any better :)

> I'm sure the only solution will be to modify Linux too, because once Windows
> 2000 does it or when BeOS has more success, no one will take multimedia
> under Linux seriously....
 
Why not?  I could be going with BeOS or something, but Linux is stable, works 
on my homebrew K6 box, and the software is _free_ and I can fix it myself.  
Can't beat that with a stick, in my humble opinion.  Besides, removing cash 
from the picture means that I don't have to care whether other people take 
Linux seriously or not.  It works for me.  If they prefer worse alternatives, 
well, screw 'em.

> KURT (kansas university real-time linux) might be an option... It allows one
> to schedule user space events... However, people won't use kernel
> modifications unless they are well supported. I don't know the future of
> KURT.
 
The future of KURT, as with the future of RT-Linux, GNU and Linux itself, 
lies with programmers like you and I.

> I wanted to code a reliable audio app and had no time to stuggle with KURT,
> ALSA drivers and Linux kernel before being able to code my stuff so I
> switched to BeOS... And I can tell you it has a very very good API.
 
I think BeOS really stands for 'Beautiful Operating System'.  It'd be nice 
if it ran on my hardware though.

> Please, try to make Linux better by advocating better user-space timing...
> If some people are interested, please let me know... I might switch back to
> Linux and learn to hack the kernel if I'm not alone.

Ok <sound of clambering onto soapbox> ..

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.  Know 
why tiny slow chips often seem to work just as well as big fast ones for 
real-time performance?  It's because of what people do with them.  The 
secret to good RT is to keep as little execution time between you and the 
events as possible.  Ataris had great timing with their 8 MHz 68000s because 
you could set up an ISR and consistently get control within a few cycles of 
an interrupt.  The OS didn't get in the way; hell, there wasn't much OS _to_
get in the way.
  Similar situation on the Mac.  Now, the Mac has a lot more going on in it 
than Ataris ever did, but on the Mac there is a very well-defined interrupt 
structure, and since it doesn't have a preemptive kernel, interrupts are used 
_only_ for real-time tasks.
  Linux is a very different story.  The freakin' kernel _runs_ on interrupts.
It encroaches very deeply into RT-land, and it is very jealous of anyone who 
tries to steal its interrupt time.  This is because the kernel is very very 
busy.  It's not designed to do things with a predictable latency, but as 
quickly as it can get to it.  That's why it makes such a great timeshare 
system (of course that applies to most all other Unices as well, except 
probably Xenix >8) )
  So, if you want to get things done _really_ right, you have to join the 
kernel.  It's not like things are any different on other machines.  On the 
Mac, if you want something done in real time, forget polling, because it 
just won't work.  You have to do it under interrupt.  Same with Windows and 
its pack of ravening DLLs.  Same with Atari, and yes, same with BeOS.
  Maybe BeOS has a better scheduling algorithm and faster context-switching.  
(Linux's is actually unusually fast, but that's not the point.)  But very good
performance can be achieved for real-time things with Linux, because of its 
marvellous modularised kernel.  ALSA itself is a gorgeous example of how to 
take full advantage of kernel modules.
  Low-level RT is difficult by definition.  And if you think it's tough on 
Linux, try programming an embedded controller.  I enjoy it personally, but 
it's admittedly not everyone's idea of fun.  You're worried that keeping 
RT in kernel-space will scare people off?  I think current Linux installs 
do a fine job of that - not that I have a beef with 'em, but Linux is Unix:
hard to learn, but easy to use.  It's things like ALSA which are starting to 
make the system easier to deal with.  Something like what I'm trying to do 
is very, very difficult under OSS.  With ALSA it's possible for me to do it 
in such a way that others can easily benefit, without having to know the ins 
and outs of how it works.  Sorry, but I need less than 10% jitter on my MTC:
I'll write my timecode generator in kernel-land where ALSA lives, thanks 
very much.

<cue sound of clambering off soapbox while ducking to avoid tomatoes and 
chainsaws>

Cheerio,
Michael Ashton


