On May 20, 2004 01:20 pm, Jeremy Penner wrote:
> Hello,
>
> 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'll take any help I can get :)
> 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?
A little more info is required. Previously, there was a busy wait in the
SDL sound code that waited until all but 100 and some odd ms of sound
samples were left. Then it returned. The problem there was the
combination of waiting in the video thread and busy-waiting in the sound
thread caused jumps and skips in the whole emulation. But the sound
*did* work better (at the expense of burning CPU and skipping video). So
yes, the SDL sound code never did work as well as we wanted. And since
this is the first time the SDL codebase was compiled for Windows, we're
seeing the problem even more prominently.
> 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.)
If you mean there are no other sound backends, then yes, Stella audio is
now SDL based. In fact, the whole codebase is now SDL based. I'll try
your suggestion.
> > 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.)
I mean *all* sound generation changes. I'll get you more info on that.
> > 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?
Yes, it falls behind more and more as time passes. If it were behind the
same amount at all times, that at least would be tolerable. As it is,
the longer you play a game, the more the sound goes out of sync. Now,
the sound itself would 'sound' fine; it just wouldn't be synced with
video. If I paused the emulation and waited until the sound finished
playing and then started again, all would be well (for a time).
> Random question: Is SoundSDL::update ever called? If so, when?
Right now, there are two approaches. First, if I'm not worrying about the
digital sound support, then SoundSDL::update() is called once per
scanline. It fills a queue with samples generated by TIA_process().
In the second case, if I'm trying to get digital sound support, the
SoundSDL::update() method doesn't actually do anything. In this case,
the SoundSDL::set() method does all the work. This method is called
whenever a sound register write is done.
Neither approach works the way I want.
> 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 don't.
I did have them enabled. They were just disabled recently to see if it
makes a difference. It doesn't, so I can re-enable them.
> - 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'll give this a try.
> I hope this helps out somewhat. My apologies for being unable to sit
> down and tackle it properly.
Any help is appreciated. Do you mind if I contact you again if I have any
questions? And would you prefer this list or your personal email
address?
Thanks,
Steve
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
