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:
> 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

One reason I asked is that my sound synthesis software runs at 46 cycle
period. ;-)

> 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