3 ms·

The main issue is that in MAME's normal operation it waits for the start of a new video frame, runs all the emulation as quickly as possible, and then sleeps th

The main issue is that in MAME's normal operation it waits for the start of a new video frame, runs all the emulation as quickly as possible, and then sleeps the rest of the frame time. (so-called "hurry to sleep" that became a big deal on phones). That works fine for games and computers and even Game and Watches, but it introduces lag when talking to the outside world. Even that is OK for serial/parallel and Ethernet comms with emulated machines, but MIDI is a special case where there's enough lag between pressing a key and hearing it that even crappy players like myself get completely discombobulated. You can record what you want separately as a MIDI sequence and then play it through the synth in MAME to get a .WAV you can paste into a DAW, but MAME as a real-time workflow isn't there yet. Our basic plan is to increase the "frame rate" for synths significantly (to something like 240 Hz) but there are of course complications with that that we need to work through.

nyanpasu64 3y ago
I found that Dolphin uses OS sleeping to run the emulation roughly in sync with wall-clock time, and use a dynamic-rate audio resampler to output sound with a bit of added latency. This has the complication that frame delivery is no longer synchronized with monitor refresh, and requires VRR displays (unlike an actual Wii) for low-latency output. I had a draft PR to loosely couple the sleeps with "frame queuing delay", but it didn't get merged. In the case of writing an audio synth, I think the usual approach is to "hurry to sleep", but synchronized with the audio device/OS mixer's 2-3 audio buffer periods/pages (rather than visual frames), and asynchronously update the UI. Are you planning to use wall-clock time, or the audio sample clock, as the source of truth for timing?
datpiff 3y ago
Thanks for commenting. I assume that emulating on a video frame basis is so ingrained in MAME that it's hard to drop?

nyanpasu64 3y ago

I found that Dolphin uses OS sleeping to run the emulation roughly in sync with wall-clock time, and use a dynamic-rate audio resampler to output sound with a bit of added latency. This has the complication that frame delivery is no longer synchronized with monitor refresh, and requires VRR displays (unlike an actual Wii) for low-latency output. I had a draft PR to loosely couple the sleeps with "frame queuing delay", but it didn't get merged. In the case of writing an audio synth, I think the usual approach is to "hurry to sleep", but synchronized with the audio device/OS mixer's 2-3 audio buffer periods/pages (rather than visual frames), and asynchronously update the UI. Are you planning to use wall-clock time, or the audio sample clock, as the source of truth for timing?

datpiff 3y ago

Thanks for commenting. I assume that emulating on a video frame basis is so ingrained in MAME that it's hard to drop?