Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!usc!ucsd!ucbvax!bloom-beacon!portnoy
From: portnoy@athena.mit.edu (Stephen L. Peters)
Newsgroups: comp.sys.next
Subject: Re: Using DSP as a modem
Message-ID: <1990Nov7.202451.10186@athena.mit.edu>
Date: 7 Nov 90 20:24:51 GMT
References: <10363@ubc-cs.UUCP> <10722@milton.u.washington.edu>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: Massachusetts Institute of Technology
Lines: 19


>>In general, I guess this is a problem of multiple applications trying
>>to access the DSP at the same time.  I wonder how this is handled...

>    Last I checked, when you reserve the DSP, you specify an arbitration
>port or arbitration callback, so that if someone else wants the DSP
>while you have it you do know about this and can give it to them if
>you want. I doubt they can wrest control without your process' consent,
>though. (In the case of beeps, they probably get lost -- try playing a long
>soundfile, and beeping. No noise.)

I was playing with a demo machine a little while back and had a ray
tracing operation working (I assume that it uses the DSP to do matrix
calculations), when I decided to play a score file.  The program
returned a message saying that it couldn't access the DSP port because
it was busy.  I assume that you can program your applications to wait
until the DSP port is free before proceeding...

				Stephen Peters