johnhlee@cory.Berkeley.EDU (Vince Lee) (08/06/89)
HELP!!!!!!! I have written an application which uses the timer device and I am getting TONS of mysterious crashes. The programs plays sound effects in response to events in the input stream (key clicks, disk insertion, etc) The samples are stored in fast RAM, and instantaneously copied to a chip buffer (which is allocated on the fly) before playing. To de-allocate the buffer, I set up the timer device to flag me when I've calculated the sample will have finished playing. This all works fine. The problem occurs when I get, say, another keyclick and want to override the sample being played. I simply stop the audio, free the chip buffers, and call: AbortIO(timerRequest); WaitIO(timerRequest); I have tried all combinations of WaitIO/GetMsg/WaitPort.. etc, and every other way I know of doing the same thing, and yet the addition of this code causes the program to crash (the whole system to lock up actually) after about a minute of typing (with a typewriter sample tied to a keystroke). I have had problems aborting the timer device in a previous program, and recall that I never resolved it. The rest of the timer code consists of the timer example code from Commodore (Fish ? #2). Does the timer device have some bugs I don't know about? Thanks in advance. -Vince
farren@well.UUCP (Mike Farren) (08/07/89)
johnhlee@cory.Berkeley.EDU.UUCP (Vince Lee) writes: >The samples are stored in fast RAM, and instantaneously copied to a ^^^^^^^^^^^^^^^ >chip buffer (which is allocated on the fly) before playing. Boy, howdy! I'd sure like to know how that one works! Ramdisks will never be the same... :-) -- Mike Farren farren@well.sf.ca.usa
johnhlee@cory.Berkeley.EDU (Vince Lee) (08/10/89)
In article <13041@well.UUCP> farren@well.UUCP (Mike Farren) writes: >johnhlee@cory.Berkeley.EDU.UUCP (Vince Lee) writes: >>The samples are stored in fast RAM, and instantaneously copied to a > ^^^^^^^^^^^^^^^ >>chip buffer (which is allocated on the fly) before playing. > >Boy, howdy! I'd sure like to know how that one works! Ramdisks will >never be the same... :-) Yes, there is an undocumented timer device command which allows you to do this; which is another reason I use the timer device instead of making the program interrupt-driven. The command, CMD_STOPTIME is little-known, but will be in the 1.4 RKM's. It temporarily pauses the timestream allowing copying operations to occur with no time delay. Unfortunately, it requires the ECS, and will therefore not work on an A1000. A side effect of the command, however is that if called frequently, it makes interlace jitter considerably worse. >-- >Mike Farren farren@well.sf.ca.usa
karl@sugar.hackercorp.com (Karl Lehenbauer) (08/13/89)
In article <16074@pasteur.Berkeley.EDU>, johnhlee@cory.Berkeley.EDU (Vince Lee) writes: > To de-allocate the buffer, I set up the timer device to > flag me when I've calculated the sample will have finished playing. Why don't you just free it when you get reply messages from audio.device from all the pending requests to play that sound? > The programs plays sound effects in response to events in the input stream > (key clicks, disk insertion, etc) The samples are stored in fast RAM, and > instantaneously copied to a chip buffer (which is allocated on the fly) > before playing. ...exactly how 'chatterbox' works; it's waiting to be shipped out by the moderator. -- -- uunet!sugar!karl Official Opinions of Hackercorp -- Clip and Save -- free Usenet access: (713) 438-5018