sritchie@cs.ubc.ca (Stuart Ritchie) (11/07/90)
The idea has been floating around since the beginning, and it's a nifty idea alright... but wouldn't this complicate local sound a tad? Suppose you were connected somewhere, using your (hypothetical) NeXT DSP-based modem. Since the DSP chip is busy acting as a modem, what happens when an application wants to generate some audio? (eg, ^G) 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... --- sritchie@cs.ubc.ca | Stuart Ritchie | ..you think that's impressive? Dept. of Computer Science | Just wait until next year... University of British Columbia | ---
wiml@milton.u.washington.edu (William Lewis) (11/07/90)
In article <10363@ubc-cs.UUCP> sritchie@cs.ubc.ca (Stuart Ritchie) writes: >The idea has been floating around since the beginning, and it's >a nifty idea alright... but wouldn't this complicate local sound >a tad? Now, what THIS box needs is *2* DSPs! Yeah! =8) ... >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.) -- wiml@milton.acs.washington.edu Seattle, Washington (William Lewis) | 47 41' 15" N 122 42' 58" W "These 2 cents will cost the net thousands upon thousands of dollars to send everywhere. Are you sure you want to do this?"
portnoy@athena.mit.edu (Stephen L. Peters) (11/08/90)
>>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