Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!umd5!feldman
From: feldman@umd5.umd.edu (Mark Feldman)
Newsgroups: comp.sys.next
Subject: Re: Real Time and Mach
Message-ID: <4614@umd5.umd.edu>
Date: 14 Mar 89 23:52:33 GMT
References: <2897@eos.UUCP>
Reply-To: feldman@umd5.umd.edu (Mark Feldman)
Organization: University of Maryland, College Park
Lines: 33

In article <2897@eos.UUCP> phil@eos.UUCP (Phil Stone) writes:
>Thanks for the info on sampling rates and the NeXT, everybody.  As I
>thought, the maximum stand-alone sampling rate is 44.1 Khz.  Ali Ozer
>mentioned a company that has announced an add-on that will allow
>88.2 Khz in monoaural.  I will look into this for details.

Out of the box, the only easily utilized sampling input is a mono microphone
input sampled at telephone line quality (8k 8bit samples/second).  This
limit is due to the A/D converter (not to be confused with the D/A converter
that outputs those wonderful sounds).  The add-on that Ali mentioned is an
A/D converter capable of sampling at much higher rates that connects to the
DSP port on the NeXT.  I'm sure that with the appropriate hardware plugged
into the DSP port, you'll be able to sample at very high rates.  Perhaps
it's not to difficult to interface to the DSP port, but I haven't seen any
specs so I don't know.

>Next area of concern:  how is Mach for real-time applications?  Have
>any of the HP-style kernal-preemption hacks been added?  What's the
>scheduling like (timer granularity, signal implementation, etc)?
>Note that I only know enough about this stuff to get me into trouble,
>but even on so-called Real-Time Unix (tm) on the MassComp, several
>shortcomings have appeared in our experiments.  I need to know if things
>will be better or worse with Mach.

Mach looks to be a winner as far as real-time goes.  The idea behind Mach
was to provide a small, efficient kernel to handle memory management,
interprocess communication, and scheduling.  The goal of Mach is to bring us
what UNIX could have been if it was done right the first time and the kernel
hadn't been hacked and added-to to death (please, no flames).  The current
scheduling seems to be somewhat unfair, but that can be attributed to
point-eightness.  

	Mark