Re: Pitchforking timing code, paving the way to a Gold edition of Jace

[Michael J. Mahon <mjmahon@aol.com>]

BLuRry <brendan.robert@gmail.com> wrote:
> The problem with being the sole maintainer of a program is that nobody is
> standing over my shoulder to call bull***t on some of the older bits of
> code.  That being said, I've been trying to figure out why on earth the
> Mockingboard timing is off when the emulator starts, but then sounds OK
> after I reinitalize the mockingboard.  Turns out it was a battle of code
> synchronization efforts that were all going head-to-head and I didn't
> realize it until running a profiler and observed the thread interactions.
> 
> 1) The motherboard thread has its own timer which is used to keep the
> emulator running at the expected 1mhz timing.  The CPU goes for 10,000
> cycles or so and then after that interval, the timer takes a measurement
> of how many milliseconds have ellapsed.  If the emulator completed over
> 10ms too early, then the CPU thread is told to sleep for a while to let
> the time catch up.  In general practice, this works OK when sound isn't playing.
> 
> 2) When speaker sound is active, a sample is taken every 24 cpu cycles. 
> When enough samples fill a buffer, a separate playback thread wakes up
> and consumes the buffer. 

Since you are approximating a 44.1kHz sample rate, taking a sample every 23
Apple cycles is a closer approximation. Is there some other reason for
choosing 24 cycles?

-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon