Re: Aw: Re: [stella] The future of Stella (i.e. debugger needed)

Subject: Re: Aw: Re: [stella] The future of Stella (i.e. debugger needed)
From: "Jeremy Penner" <jeremy@xxxxxxxxxxxxxx>
Date: Thu, 20 May 2004 10:50:20 -0500 (CDT)

I understand sound.  If I had a free weekend, I would happily hunt down
and crush your Stella sound bugs properly.  However, for now I'm at work
at a machine without a sound card or CVS client, so I'll do the best I can
with what we've got.

I'm a bit confused as to what exactly has changed between 1.3 and now,
beyond moving createAudioSamples out of TIA.cxx and into SoundSDL::set...
was the SDL driver this bad before?

Stella audio is now exclusively SDL, right?  Save yourself some headache
and let SDL do the conversion between the TIA's frequency and the PC's. 
Call SDL_OpenAudio with a NULL pointer for the second parameter and then
you can happily send it raw TIA audio at 31400hz.  This should narrow your
problems down, at least.  (No need to do resampling.)

> The main problem I'm having is that (1) not enough samples are being
> produced per frame to account for Pitfall2 and Quadrun (digital sound),
> and (2) in Windows, the sound is dropping out because the buffer size I
> use, and If I use a larger buffer size, the sound changes pitch.

For #2, do you mean the *digital* sound changes pitch?  Because it doesn't
make much sense that the normal TIA sound would change pitch with buffer
size.  (Unless, I suppose, that the larger buffer size is changing the
allowable playback rate and triggering a problem with your resampling code
in TIASound.c, which does look like it could very easily have some fun
rounding problems.)

> One partial solution is in the attached 'SoundSDL.cxx' file.  In the
> SoundSDL::set() method, in the section '#if defined(DIGITAL_SOUND)', we
> see there is a way to generate the correct # of samples.  This is the
> way Stella 1.3 worked.
> The problem with this approach is that now, *too many* samples are
> created per second.  If I let the SDL audio callback process them as it
> needs them, the sounds come out correct, but we lose a/v sync, since
> the audio callback falls behind the video rendering.  My guess would be
> that some sort of resampling has to be done, so that the # of samples
> created is precisely what SDL wants, but it still includes all the
> sample information as before (a resampling compression algorithm, if
> you will).  My guess is this is what z26 does.

By this you mean it falls more and more behind as time passes, not that it
simply lags behind a bit?

Resampling while retaining pitch is not something you want to be a part
of.  *Especially* in realtime sound code.  Trust me.

Here is the problem: 1 sample (at 31400hz) =
37.898089171974522292993630573248 cycles.  It's not very straightforward
to try and generate the exactly correct number of samples ahead of time
without rounding errors, especially if you're trying to do it for any
sample rate.  The way z26 appears to try and get around it is really quite
simple -- it doesn't fill up the queue all the way, and then when it comes
time to generate the last bit, it generates sound with the current TIA
settings right up to the end of the PC's buffer.  This is a reasonable
approximation with good results.

Random question: Is SoundSDL::update ever called?  If so, when?

So, here would be my suggested solution:

- First, you should really be doing SDL_LockAudio()s around your sample
queue.  It probably isn't the source of any of your current headaches, but
it would be happy to be the source of plenty of subtle, future ones if you
- In SoundSDL::callback, when you run out of buffer, call Tia_process to
get the remaining samples.  (Don't add any more to the buffer.)  Update
sound->myLastSoundUpdateCycle to the current system cycle (make sure you
do this in a threadsafe way).  My guess is that when you did processing in
the SDL callback previously, you didn't do this?  That would definitely
make the sound lag.

I hope this helps out somewhat.  My apologies for being unable to sit down
and tackle it properly.

Jeremy Penner            

Archives (includes files) at
Unsub & more at

Current Thread