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

[BLuRry <brendan.robert@gmail.com>]

A good question, and the exact answer is that I was only approximating for the sake of the message.  I actually calculate the interval as a double and that takes care of the modulo.  ;-)

I tried to update the code to use more modern java synchronization (specifically, the Exchanger class to swap audio buffers) but the result was terrible compared to my other solution.  However, using tighter locking semantics has improved the video sync and lowered CPU usage a little bit.  If anything, it puts most of the thread synchronization in the hands of the OS with less kludgy workarounds in the way.

Things are looking good for an official build -- I just need to do some final testing and play with it for a couple of days to make sure the wheels don't fall off.

-B

On Thursday, August 23, 2012 3:42:20 PM UTC-5, Michael J. Mahon wrote:
> 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