Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!sugar!karl From: karl@sugar.hackercorp.com (Karl Lehenbauer) Newsgroups: comp.sys.amiga.tech Subject: Floppy I/O causes delays getting timer.device messages Message-ID: <4014@sugar.hackercorp.com> Date: 13 Jul 89 00:17:02 GMT Organization: Sugar Land Unix - Houston Lines: 47 [Whew. This was one mean mother. I had about given up.] I assert that floppy I/O causes noticeable delays in getting messages back from the timer device. My proof is as follows: My SMUS player is rock solid when the Amiga is just sitting there. It is even solid when doing lots of hard disk I/O and/or window resizing, relocating, etc. (The SMUS player sets its priority up to 35 or so) When doing floppy I/O, indeed even when any of the floppy drives don't have a disk inserted, the SMUS player will encounter noticeable delays in playing voices. (When a disk is not inserted, the delays correspond to the clicks the drives make.) (Note that the SMUS player accounts for its own and others' CPU time consumption by using the precision realtime timing routines by Paul Higginbottom as modified by me to determine when in the future the next realtime event is to occur; it then makes a request to timer.device to get a message at that next point in time.) Anyway, the delays were maddening, and would have meant that any games I do, etc, would not be able to play music while loading, or I would have to butt long samples together a la the Newtek Demo Reel 1, i.e. samples of a couple measures of the song at a time, rather than the SMUS player playing notes.) As a last attempt to get the SMUS player to play steadily while the floppy was in use, I created a timer interrupt routine that used one of the two free (well, quasi-free) timers that, instead of providing a reference, actually produced a signal to the SMUS player that said "advance one time unit." Using this method of generating time, the SMUS player is totally solid even while formatting floppies, copying them, doing directories, reading and writing files, etc. I am open to any refutation of this assertion. As it is, I'm ecstatic that the thing is working now, but bummed out that I had to jack around so much to make it go. SoundScape screws up during floppy I/O too, but I haven't tried it with the SmoothClocker clock module. Tired but happy,