phil@eos.UUCP (Phil Stone) (03/15/89)
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. 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. Thanks, Phil Stone (phil@eos.arc.nasa.gov / ames!eos!phil)
feldman@umd5.umd.edu (Mark Feldman) (03/15/89)
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
ali@polya.Stanford.EDU (Ali T. Ozer) (03/16/89)
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. Some more info: The maximum data rate into the DSP is apparently 2.5 Mbits/sec, synchronous. Starting from this info and assuming a 16-bit sampler, it seems like you should be able to get a maximum sampling rate of about 156 kHz (2.5 Mbits/sec / 16 bits/sample). The Digital Ears info sheet I have indicates that it can do 88.2 khz (using 16-bit samples). At that sampling rate, you get about 11 microseconds per sample. The DSP runs at 25 MHz, and most instructions are 2 clocks long; thus, in 11 microseconds, you can execute about 130 instructions and do whatever you want to that data... Please feel free to let me know if the above seems incorrect. Phil Stone: If you talk to Metaresearch, you might want to confirm the above... Ali Ozer, NeXT Developer Support