karl@sugar.hackercorp.com (Karl Lehenbauer) (07/13/89)
[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, <karl -- -- uunet!sugar!karl -- free Usenet access: (713) 438-5018
jesup@cbmvax.UUCP (Randell Jesup) (07/14/89)
In article <4014@sugar.hackercorp.com> karl@sugar.hackercorp.com (Karl Lehenbauer) writes: >[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. Could be. Nothing says this can't happen. The timer is speced as sending the message back when you ask _or later_. System load (especially on the timer) can affect how much later it gets back. When the floppy is seeking, it is doing lots of 3ms (3000us) waits. When reading and writing, it does some 1 and 2ms waits, but not very often. When you consider the overhead of a time request is on the order of 800us, this is signifigant. Also, the current timer's Microhertz unit can become less accurate when being heavily accessed, from lots of stopping and restarting of the hardware timer. This should be improved in 1.4. >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.) This is the proof. The clicks are combined with the 3ms stepping (and 15ms settle) timer waits. You came up with the right solution: don't use the timer device for short, high-accuracy waits: use a free hardware timer (see posted message or CATS about which one to use and how to allocate it.) -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"