5 ms·

Ever since the MESS merger, MAME has been emulating anything and everything: old consoles, computers, terminals, LCD games. Synthesizers just seem like a logica

Ever since the MESS merger, MAME has been emulating anything and everything: old consoles, computers, terminals, LCD games. Synthesizers just seem like a logical next step. Only drawback seems to be it's gonna be difficult to get performance real-time enough to use as an actual musical instrument. Maybe when MiSTer cores show up for these synths, it'll change that.

datpiff 3y ago
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.
tomphoolery 3y ago
> Only drawback seems to be it's gonna be difficult to get performance real-time enough to use as an actual musical instrument. Kinda depends on whether the "sound chip" is emulated. For example, the MOS6581 doesn't seem to be emulated here. You could emulate the UI and controls of an Elektron SIDStation, but you wouldn't be able to get the sounds to play unless you had a real SID chip in there. So in that sense, just running the UI and controls would be fine for an emulator if there was a real MOS chip somewhere to take in audio.
- RB_MAME 3y ago
  MAME emulates the SID but the code dates back to like 2004 and doesn't sound anywhere near as good as the modern SID emulation engines. We prefer BSD or MIT licensed components to GPL ones so there's been some hesitation to just grab one of the popular SID engines (and our base C64 emulation is generally decent if you aren't trying to break the hardware like most demos, but it's also slow because the mapper PLA is emulated in the hot path).
- Luc 3y ago
  I'm confused. There might not be one in Mame right now, but there's dozens of SID chip emulators. For example this website uses WebSID to play SID tunes in your browser: https://deepsid.chordian.net/ https://deepsid.chordian.net/
- anthk 3y ago
  That SID I think it's emulated since the first emulators for the C64 if not before.
- xcv123 3y ago
  Of course the sound chip is emulated. That's the purpose of MAME. It emulates everything in the original hardware, sound included.
  - vikingerik 3y ago
    For quite a while, MAME didn't always emulate sound chips. A number of games early on worked by way of prerecorded sound samples triggered at the appropriate times.
TheRealPomax 3y ago
Computers are really powerful these days, though, it's why physical modeling VSTi are actually usable now. Especially if you do the signal processing on the GPU instead of the CPU (which is thankfully starting to happen as well).
- munificent 3y ago
  > Computers are really powerful these days, though, it's why physical modeling VSTi are actually usable now. True, but simulating analog oscillators and filters well with little aliasing and good support for resonance is still quite hard. Current virtual analog synths sound good, but the first time I sat down with a real (but cheap and shitty!) analog synth, I was blown away. > Especially if you do the signal processing on the GPU instead of the CPU (which is thankfully starting to happen as well). There's some stuff you can do here, but my understanding is that it's pretty limited. GPUs are designed for wide parallel computation, which makes sense in graphics where pixels are relatively independent of each other. A GPU is trying to calculate many things at a single point in time in parallel. Audio is about calculating a small number of things (just a few samples) but at a very high frame (sample) rate, and the things you're calculating often depend heavily on the results of previous points in time. There's a lot more fundamentally serial work to do, which makes it hard to map to GPUs.
MenhirMike 3y ago
> Only drawback seems to be it's gonna be difficult to get performance real-time enough to use as an actual musical instrument. Is there something specific about the MAME codebase that makes this an issue? There are quite a few software emulations of classic synths, for example Arturia's V Collection or the Plogue's Chipsounds - and those work perfectly well in real time even on lower end machines. Roland's Virtual Analog (I hate that term) and Plug-Out also exists, though I really don't want their cloud subscription just so I can download an instrument into a physical synth. But I'm not familiar enough with the MAME codebase to know if there's something in there that could cause issues.
- bluGill 3y ago
  More that synthesizer. Some are easy to emulate, while others require a lot more CPU cycles.
rgreasons 3y ago
There are musicians that would love to use hardware-based emulation for recording and would happily settle for current software-based solutions for live performance. Many professional musicians already do this. Musicians such as Floating Points have studios filled to the brim with large, rare, expensive synthesizers[1] with which they don't travel. Existing VSTs and reproductions get you 90% of the way there, but MAME emulation may be able to bring higher-quality emulation to a wider set of musicians. [1] https://www.youtube.com/watch?v=75iX1rnW9WQ https://www.youtube.com/watch?v=75iX1rnW9WQ

datpiff 3y ago

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.

tomphoolery 3y ago

> Only drawback seems to be it's gonna be difficult to get performance real-time enough to use as an actual musical instrument. Kinda depends on whether the "sound chip" is emulated. For example, the MOS6581 doesn't seem to be emulated here. You could emulate the UI and controls of an Elektron SIDStation, but you wouldn't be able to get the sounds to play unless you had a real SID chip in there. So in that sense, just running the UI and controls would be fine for an emulator if there was a real MOS chip somewhere to take in audio.

RB_MAME 3y ago
MAME emulates the SID but the code dates back to like 2004 and doesn't sound anywhere near as good as the modern SID emulation engines. We prefer BSD or MIT licensed components to GPL ones so there's been some hesitation to just grab one of the popular SID engines (and our base C64 emulation is generally decent if you aren't trying to break the hardware like most demos, but it's also slow because the mapper PLA is emulated in the hot path).
Luc 3y ago
I'm confused. There might not be one in Mame right now, but there's dozens of SID chip emulators. For example this website uses WebSID to play SID tunes in your browser: https://deepsid.chordian.net/ https://deepsid.chordian.net/
anthk 3y ago
That SID I think it's emulated since the first emulators for the C64 if not before.
xcv123 3y ago
Of course the sound chip is emulated. That's the purpose of MAME. It emulates everything in the original hardware, sound included.
- vikingerik 3y ago
  For quite a while, MAME didn't always emulate sound chips. A number of games early on worked by way of prerecorded sound samples triggered at the appropriate times.

TheRealPomax 3y ago

Computers are really powerful these days, though, it's why physical modeling VSTi are actually usable now. Especially if you do the signal processing on the GPU instead of the CPU (which is thankfully starting to happen as well).

munificent 3y ago
> Computers are really powerful these days, though, it's why physical modeling VSTi are actually usable now. True, but simulating analog oscillators and filters well with little aliasing and good support for resonance is still quite hard. Current virtual analog synths sound good, but the first time I sat down with a real (but cheap and shitty!) analog synth, I was blown away. > Especially if you do the signal processing on the GPU instead of the CPU (which is thankfully starting to happen as well). There's some stuff you can do here, but my understanding is that it's pretty limited. GPUs are designed for wide parallel computation, which makes sense in graphics where pixels are relatively independent of each other. A GPU is trying to calculate many things at a single point in time in parallel. Audio is about calculating a small number of things (just a few samples) but at a very high frame (sample) rate, and the things you're calculating often depend heavily on the results of previous points in time. There's a lot more fundamentally serial work to do, which makes it hard to map to GPUs.

MenhirMike 3y ago

> Only drawback seems to be it's gonna be difficult to get performance real-time enough to use as an actual musical instrument. Is there something specific about the MAME codebase that makes this an issue? There are quite a few software emulations of classic synths, for example Arturia's V Collection or the Plogue's Chipsounds - and those work perfectly well in real time even on lower end machines. Roland's Virtual Analog (I hate that term) and Plug-Out also exists, though I really don't want their cloud subscription just so I can download an instrument into a physical synth. But I'm not familiar enough with the MAME codebase to know if there's something in there that could cause issues.

bluGill 3y ago
More that synthesizer. Some are easy to emulate, while others require a lot more CPU cycles.

rgreasons 3y ago

There are musicians that would love to use hardware-based emulation for recording and would happily settle for current software-based solutions for live performance. Many professional musicians already do this. Musicians such as Floating Points have studios filled to the brim with large, rare, expensive synthesizers[1] with which they don't travel. Existing VSTs and reproductions get you 90% of the way there, but MAME emulation may be able to bring higher-quality emulation to a wider set of musicians. [1] https://www.youtube.com/watch?v=75iX1rnW9WQ https://www.youtube.com/watch?v=75iX1rnW9WQ