If the period of not being able to emulate at full speed lasts long enough no
amount of buffering is going to help though, since audio is consumed at a
faster rate than it is generated. There’s also the problem that you wouldn’t
know that you need extra buffering until it’s already too late (when you’re
already emulating too slowly).
Oh, I was thinking in terms of hard limits here; what it takes to deal
with not being able to run at an actual steady 60 fps.
The emulator will have to catch up by dropping frames on way or
another, in order to maintain the nominal 60 fps internally. There’s
just no way around this, whether it’s an emulator or a native video
Stretching would help if you e.g. generate twice as many samples
(slowing the sound down to half speed) if you’re only able to
maintain 30 FPS. Sounds wonky though.
But, what’s the point in that? I would think the top priority in most
cases is to run the applications in real time, rather than rendering
every single frame.
Adjusting the playback rate very slightly (hopefully inaudibly) is used
in some modern emulators to make sure you never under- or overflow
(keep the audio buffer fill level consistent).
You’ll definitely need to do that one way or another in any real time
audio application, as sample rates and refresh rates are only so
accurate, and not synchronized on the hardware side.
The only exception would be oddball hardware that actually drives the
audio CODEC from the same clock as the video subsystem - and I believe
those days ended shortly after the Amiga, as far as computers go.
Low-level sound emulation
gets messy since you basically have a single infinite "sound effect"
playing at all times, which needs to be perfectly synchronized to video.
Well, you could always separate control register writes from the
actual audio rendering, but that’s going to result in all sorts of
interesting artifacts with anything but the most trivial sounds…
(Stalling arpeggios, rumble/noise that occasionally turns into square
waves etc.) Too low level interface for that kind of stuff.
If you try to simply generate samples at the backend’s sample rate
without doing any monitoring or adjustments, you’ll eventually
under- or overflow purely due to jitter. Stuff like that is why many
emulators like to have crappy sound.
Of course. Same problem as video players, soft synths and anything
else that needs to deal with multiple streams driven by independently
clocked hardware. Rates are only approximate, not stable, and not
Yeah, I think I’ll try this approach (after upgrading to SDL 2 just in case
that helps). Would be nice if there was a non-blocking version of SDL_Flip()
that returned a status and a new buffer pointer or something, but maybe it’s
a bit specific…
I’m not sure that’s possible to implement over all platforms and APIs,
so it would probably be one of those bonus features you can’t rely
entirely on. However, if you’re doing the software rendering in
another thread and only uploading and rendering in the main thread,
you can sort of implement that anyway.On Sun, Oct 6, 2013 at 12:28 AM, Ulf Magnusson wrote:
//David Olofson - Consultant, Developer, Artist, Open Source Advocate
.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |