5 ms·

Does MAME have some kind of latency issue with the synth implementations? Why wouldn't it be real-time already? The MIDI protocol tops out at ~1000 message/sec

Does MAME have some kind of latency issue with the synth implementations? Why wouldn't it be real-time already? The MIDI protocol tops out at ~1000 message/sec and no real synth ever needed control message anywhere near that frequently. Why would you need an FPGA?

RB_MAME 3y ago
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?
pantulis 3y ago
I guess it's because MAMEis not emulating the software of these devices, it's emulating the whole hardware and then puts the ROMs on top of it. It's like running a synthesizer virtual machine. I understand most commercial vintage synth plugins either use samples of the real stuff --boo! or they emulate the wave functions and effects used on those devices from the manufacturer documentation, but not the exact hardware.
- datpiff 3y ago
  It's been done for the Access Virus, Waldorf MicroQ and some other Motorola 56k synths https://dsp56300.wordpress.com/ https://dsp56300.wordpress.com/, all usable as real-time instruments.
  - pantulis 3y ago
    Very cool, thanks for the info. I did not mean to say that MAME were the first trying to do exact hardware emulation for synths, just that emulating hardware means a higher workload for the computer. As a note, I see that this project has created its own CPU benchmarks to make sure you can confidently run the emulations with acceptable results so while perhaps their emulation code is more efficient than MAME's --who knows-- the difficulty remains the same.

RB_MAME 3y ago

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?

pantulis 3y ago

I guess it's because MAMEis not emulating the software of these devices, it's emulating the whole hardware and then puts the ROMs on top of it. It's like running a synthesizer virtual machine. I understand most commercial vintage synth plugins either use samples of the real stuff --boo! or they emulate the wave functions and effects used on those devices from the manufacturer documentation, but not the exact hardware.

datpiff 3y ago
It's been done for the Access Virus, Waldorf MicroQ and some other Motorola 56k synths https://dsp56300.wordpress.com/ https://dsp56300.wordpress.com/, all usable as real-time instruments.
- pantulis 3y ago
  Very cool, thanks for the info. I did not mean to say that MAME were the first trying to do exact hardware emulation for synths, just that emulating hardware means a higher workload for the computer. As a note, I see that this project has created its own CPU benchmarks to make sure you can confidently run the emulations with acceptable results so while perhaps their emulation code is more efficient than MAME's --who knows-- the difficulty remains the same.