Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!caen!sdd.hp.com!wuarchive!uunet!cbmvax!daveh From: daveh@cbmvax.commodore.com (Dave Haynie) Newsgroups: comp.sys.amiga.advocacy Subject: Re: AMIGA Message-ID: <21400@cbmvax.commodore.com> Date: 8 May 91 19:33:39 GMT References: <1553@ewu.UUCP> <&i4Gzkv*1@cs.psu.edu> <21321@cbmvax.commodore.com> <5060@dirac.physics.purdue.edu> Reply-To: daveh@cbmvax.commodore.com (Dave Haynie) Distribution: usa Organization: Commodore, West Chester, PA Lines: 68 In article <5060@dirac.physics.purdue.edu> murphy@gibbs.physics.purdue.edu (William J. Murphy) writes: >In article <21321@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >>In article <&i4Gzkv*1@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes: >>>NeXT needed to have sound in the machine. An IBM beep wasn't good >>>enough. >>Sure it was. This is a Workstation, they keep telling me. What do you need >>sound for? >Our research group is in an unusual situation in that we actually do use the >16-bit sound quite regularly. That's a typical application for an expandable personal computer. Sure, the NeXT can do this, and may in fact be a very good computer for your particular needs. However, that's not to say, looking at it the other way, that this audio hardware was a good allocation of limited resources for a company like NeXT, trying to build a general purpose workstation. It obviously has some use, but seems far too gee-whiz to me. >If the DSP were shared with the system as everyone else has suggested >then the sampling would not be assured to be continuous since some other >process could preempt the DSP controlling the sampling. I think that the >people who chose to make the DSP separate were wise. Except, that's not how DSP operating systems work. A DSP "exec" would break things down into a possibly programmable time window. Within each window, each task in a realtime queue gets as much time as it needs, then exits. The next one in turn gets scheduled. If there's any time left over, perhaps the non-realtime tasks would get scheduled preemptively. This way, multiple processes can have multiple realtime DSP operations going on, at lest until there's no more time to get them all done. It's prefectly possible to saturate a DSP just as it is any traditional CPU. However, in a real good system, the addition of a few more DSPs on an expansion board would transparently solve the saturation problem by allowing the various tasks, both realtime and non-realtime, to get scheduled on these multiple DSPs. Assuming, of course, you had an expandable system. >Not to flame the Amiga, but where can I get 16 bit sound for it? Well, this new board from SunRize does 16 bit in and out with a 56001 on board to help out. Another company working with DSP, for more scientifically oriented applications, is Active Circuits. I don't what, if anything, they have in the way of audio band CODECs, though. >I haven't been following the Amiga for the last 1/2 year, but until that time >I hadn'tseen a board that handled 100 kHz A/D and D/A. Is that what the NeXT can manage? I've never heard what they do for a CODEC in the thing. For the Amiga market, I would imagine 16 bit stereo in/out at 44.1kHz and 48kHz sampling would be far more important than mono at 100kHz, which is more of a special purpose thing. >To be fair, I did see a board by the company that makes AudioMaster? in the >latest issue of Amiga World. It has a 56000 (imagine that 8-)) and some >other software to run it. I didn't read it carefully. I assume that it can >do 16-bit out with some reasonable speed. That's the one I mentioned above. You could no doubt find any number of these kind of things for ISA bus, but of course that means your programmers all suffer. >Bill Murphy -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "That's me in the corner, that's me in the spotlight" -R.E.M.