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) |
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'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 don't. - 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 -- Jeremy Penner http://www.sporktania.com/ ---------------------------------------------------------------------------------------------- Archives (includes files) at http://www.biglist.com/lists/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [stella] Stella sound, John Saeger | Thread | Re: Aw: Re: [stella] The future of , Stephen Anthony |
Re: [stella] MiniDig, Manuel Rotschkar | Date | Re: [stella] MiniDig, Glenn Saunders |
Month |