> Most of the current sound API's > simply provide a buffer that you fill as and when you see fit, and the > sound driver empties that in "real time" for you - so all your emulation > engine has to do is stuff the audio data into that buffer whenever it > can, and the sound driver will take care of replaying it at the right > speed for you.
The APIs I've tried (FMod, SDL, and briefly OpenAL) have a sort of callback mechanism.. where they call your function when they need more sound -- I can't just give them the sound as I produce it (at least not with the methods I've been using -- if I'm mistaken here I would certainly love to know how this can be accomplished). To work with these I've had to end up double-buffering my sound which makes it a little tricky to keep the video synced with it, but I've managed. That's one thing I did really like about DirectSound -- direct, realtime access to the buffer actually being streamed. You could poll its current playback position and everything.. right down to the sample. > 60.1? Really? That is weird... > I'd have expected it to be 59.94Hz, so that it matches the (2 x 29.97Hz) > of an NTSC picture. > I wonder why it's not? It is very bizarre. Its odd framerate is probably due to the clock settings. - 262 scanlines per frame (including VBlank time) - 341 dots per scanline - 3 dots per CPU cycle - 1789772.727272 CPU cycles per second The PPU (GPU) and CPU are both driven by the same clock rate, so the ratio between dots and CPU cycles is fixed. With such rigid timings, getting the exact 59.94 Hz probably would've been difficult with the hardware used, so it was approximated. (1789772.727272 * 3) / (262 * 341) = ~60.098 I suppose they could have slowed the clock down a bit to get closer to the 59.94. At any rate, NTSC displays seem to be flexible enough to accomidate the slight framerate change. The SNES was similar. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
