The strange case of BeOS, SRS and the silent Power Mac 6500

Suppose we're working with 1024 frames, ie in stereo that's 2048 x 16-bit samples = 4096 bytes, enough to make about 24ms of audio at 441.kHz and due to a screw-up in the driver or subtle difference in how the hardware works, we're only delivering those frames to the card just after they're needed. Maybe 4 frames of audio are emitted before out 4096 bytes arrive on the card, so those 4 frames are nonsense (maybe left over from previous). This sounds... not great.

In a "low latency" mode we send less data, more often (that's what "low latency" means). Maybe we're doing 64 frames instead of 1024, but still 4 of them are nonsense because they arrive too late. Now, instead of a few frames, it's getting on for 10% of all frames that are nonsense, we can make out a tune but it's going to sound terrible.

The fact that repeatedly restarting sometimes "fixes" it can happen if it alters the relationship between when exactly the frames get sent and when the card asks for them by fractions of a millisecond, so as to adjust that 4 frames "lost". If we get it down to 0 frames "lost" it sounds perfect, 1-2 frames will sound much better than 4, while say 8 frames would sound atrocious.

The driver tried to output samples at a fixed rate, however after a lot of experimenting I found the glitches were caused when multiple interrupts conflicted (ie occurred at the same time) and the drivers was thrown off in it's Wait() timing call.

The answer was instead of waiting for a certain time to output a sample, to instead read what time it was and output the sample for that time-sample.

Worked perfectly, and also as important reduced the CPU load to only a faction of the first method.

The 7[2,3]00 is my least favorite because its plastics are the brittlest of the brittle spindlerplastics.

They will snap if you just look at them!

I still have the Performa 6400/200 I ran BeOS on back in the day and it is my favorite Macintosh of all time.