peter@sugar.uu.net (Peter da Silva) (10/21/88)
[ For the comp.sys.next people, they've been talking about using NeXT as a realtime music synthesiser, based on the DSP chip... ] One thing to consider. The NeXT machine is running UNIX (well, BSD under Mach), which is not a realtime operating system. A synth is a pretty hard- realtime environment. What do you suppose will be the likely effect of cron running sync at random times? I suppose you'd remember not to let cron start a news-unbatch during a drum solo, but I'd still be leary of it. We don't use UNIX for realtime for good reasons. On the other hand good multitasking does go very well with MIDI, as people with Amigas can attest. If they get Mach up to realtime standards this might become THE musicians instrument. Mach at least has a realtime architecture. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today? Disclaimer: I accept full responsibility for my own typos.
jbuck@epimass.EPI.COM (Joe Buck) (10/22/88)
In article <2881@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >[ For the comp.sys.next people, they've been talking about using NeXT as > a realtime music synthesiser, based on the DSP chip... ] > >One thing to consider. The NeXT machine is running UNIX (well, BSD under >Mach), which is not a realtime operating system. A synth is a pretty hard- >realtime environment. The synthesizer wouldn't run on the 68030 (though configuration of the synthesizer would), but rather on the 56001, which is designed for real-time digital signal processing. The thing has DMA channels which probably can be configured to take data from the 56001 to D/A's without intervention from the 68030 at all. >What do you suppose will be the likely effect of cron running sync at random >times? I suppose you'd remember not to let cron start a news-unbatch during a >drum solo, but I'd still be leary of it. We don't use UNIX for realtime for >good reasons. Depends. If you were having the system synthesize a pre-composed piece of music, you could structure things so the 56000 keeps things going and the 68030 just feeds commands to a queue -- no interruption at all. If you're using keyboard input, you might have slow response sometimes when the sync hits. -- - Joe Buck, card-carrying ACLU liberal jbuck@epimass.epi.com, or uunet!epimass.epi.com!jbuck, or jbuck%epimass.epi.com@uunet.uu.net for old Arpa sites
james@utastro.UUCP (James McCartney) (10/22/88)
In article <2881@sugar.uu.net>, peter@sugar.uu.net (Peter da Silva) writes: > One thing to consider. The NeXT machine is running UNIX (well, BSD under > Mach), which is not a realtime operating system. A synth is a pretty hard- > realtime environment. > Peter da Silva `-_-' peter@sugar.uu.net Which brings up a subject -- How was the NeXT music demo done (it was real time) ? and, What techniques does one use to implement real time operations in Mach or Unix ? --- James McCartney
bryant@oakhill.UUCP (Bryant Wilder) (10/22/88)
In article <3284@utastro.UUCP>, james@utastro.UUCP (James McCartney) writes: > Which brings up a subject -- How was the NeXT music demo done (it was real > time) ? and, What techniques does one use to implement real time operations > in Mach or Unix ? the NeXT demo with the violinist was done in real time using a program written by the NeXT engineers for the Motorola DSP56001. there was some question in my mind whether the general audience realized this. in fact steve came out after he had finished the intro and we talked about it. since he didn't have time to explain that it was being done in real time (the stage was torn down immediately at 12:00 noon), he figured many in the audience might think it was recorded. the real time sound doesn't interfere with the operating system once the DSP56001 program is started. the 56001 programs can be downloaded from the disk or from the operating system memory or even via the 56001's serial ports. the next machine provides the 56001 with 8K of static ram on the 56001's own address and data buses. the output sound digital data is outputed serially to the d/a converters located in the monitor and then to the output jacks. bryant wilder dsp operations manager motorola austin, texas
debra@alice.UUCP (Paul De Bra) (10/23/88)
In article <1604@oakhill.UUCP> bryant@oakhill.UUCP (Bryant Wilder) writes: >In article <3284@utastro.UUCP>, james@utastro.UUCP (James McCartney) writes: >> Which brings up a subject -- How was the NeXT music demo done (it was real >> time) ? and, What techniques does one use to implement real time operations >> in Mach or Unix ? > > >the NeXT demo with the violinist was done in real time using a program >written by the NeXT engineers for the Motorola DSP56001. there was some >question in my mind whether the general audience realized this. in fact This isn't difficult to realize at all. The IBM-AT (and clones) only have a very primitive sound generator (nothing like the DSP56001 at all, wish it did...) and a simple device driver for Xenix could generate real-time music without any problem: The device driver uses a buffer of 1024 notes (would have to be something slightly more complicated for the NeXT) so you can asynchronously fill the buffer while the music is playing. If the (small) device driver gets the highest interrupt priority it operates at real time and can generate at most 60 notes per second but that is usually enough. The NeXT can have much more intelligence in the DSP56001, to handle the buffer for instance, so Mach (and the 68030) don't have to operate in real time at all. The buffers for the DSP can be made large enough so the OS can keep the buffers filled even when the machine is heavily loaded. So not the whole OS needs to be real-time to perform some real-time operations using intelligent (real-time) periferals. Paul. -- ------------------------------------------------------------------------- |debra@research.att.com | uunet!research!debra | att!grumpy!debra | -------------------------------------------------------------------------