DSP563xx Emulator (Access Virus, Nord Lead, Waldorf MW...)

[mystran]

I don't know the details, but yeah the latest emulator version could achieve 120 MIPS (and Virus C is overclocked to 130 MHz, so 130 MIPS) by using up a whole core of an i7-4790K, and even that wasn't 100% realtime. That's quite a lot. So they are now moving towards an asmjit solution, but the trick is they cannot tell how the performance will be until all instructions are ported...

Oh the asmjit version is not in use? If these numbers are from a pure interpreter, then I don't think there's going to be any problem with running this in realtime once the JIT works as usually you get at least somewhere around an order of magnitude speedup from even naive compilation.

edit: I didn't look at how the interpreter here looks like, but generally in an interpreter you get a pretty huge overhead just from opcode dispatch, which tends to be more or less "random branches" as far as the CPU's branch predictor is concerned.

[Shiek927]

This is complete speculation, but given that there is no analog filtering, component-level modeling, etc, and all the things that make the best-sounding plugins so CPU-intensive, I don't think it will be the heaviest things around. Not super CPU-friendly because it's not as if they are explicitly made for that, but certainly not beefy tanks either.

I would expect around Diva levels of CPU usage (without the option to multicore because that's not how the DSP chip operates). Doesn't matter that there's no component-level modeling - the biggest issue is we're dealing with 24-bit to 64-bit conversion.

Also, note that these devices mostly worked at 44.1k. Forget about upsampling them for "better sound". Actually, there will have to be some resampling done on the fly to support running the plugin at other sample rates - and this will also incur a small latency and a bit more CPU overhead (if you want a good/great quality resampler).

Daaaaang, no kidding! and that's just with the Virus C which only has one Motorola chip. Something like the Nord Lead 3 or the Novation Supernova which has eight chips would be virtually impossible as-is. I guess the next step is to try and bring down the CPU intensity as much as possible

[EvilDragon]

Supernova has 6 Motorolas.

But yes - the team is working on getting things as efficient as possible.

[numerouno]

Does the DSP store 24-bit values as 3-bytes in memory? Is that what's causing the slowdowns?

edit: I took a look at the source code, it looks like it's translating each op separately?...

Let me explain some stuff in a greater detail to clear up some things

The issue is not only that we have 24 bit registers. Infact we have 24, 48 and 56 bit registers. The 56 bit registers are the ALU registers that use fixed point arithmetic. This is really something that doesn't exist on Intel at all.

Furthermore, the DSP has got a much larger status register with flags that do not exist on Intel so these status flags need to be recreated. For example:
U - Unnormalized - is set if the magnitude of a fixed point number is between 0.5 and 1.0
S - Saturation - set if a 56 bit register has been saturated while being transfered to the memory bus.
.. plus some others.

Furthermore, this DSP does not have one block of memory but three: X Y and P. While P is for program memory, X and Y are for data. The memory layout is that one address is one 24 bit word.

Note that the DSP can modify its own program while being executed and the Virus C ROM indeed does make use of this, not very often, but it does, for example when switching to multi mode / switching the preset. So this needs to be taken care of, too.

Also, the DSP has arithmetic saturation built in, and it has got an address generation unit that can do hardware modulo addressing and even bit reverse addressing.

All these things make a cheap 1:1 translation much more complex or impossible in some situations.

Now for the performance part:

Everything that has been posted so far is the performance of the interpreter. The interpreter has reached a stage where it can run a Virus C ROM without issues, but lacks performance even after weeks of optimizations with lots of profiling in VTune. As has been stated correctly, function call overhead and cache misses because of a large jump table are the key issues remaining in the interpreter code, which led to the decision that a JIT engine is needed to improve performance further.

The JIT engine is in development right now, commits are being done daily but as long as not all instructions have been converted to JIT code, there is no way to run the emulation as JIT. That is the reason why some people might think that development has stalled a bit recently, but in fact it has not
The current focus on the JIT implementation is to get it running first, performance will be the next step. Things like dependency trees and other possible shortcuts are on the roadmap indeed to improve the JIT speed once its executing the code correctly.

Finally, some clarification on multicore usage: One DSP instance will be run on one CPU core because the DSP never was a multicore DSP. But: Multiple instances can be distributed to multiple cores, so loading two plugins will definitely make use of two cores, and so on.
Also, machines that were equipped with multiple DSPs will most probably be able to execute on multiple cores, too, but right now we focus on emulation of single DSP devices first.

Hope this post helps

[Shiek927]

Thank you very much for the update and your kind answer! I have full confidence in your team and excited for this project to reach it's full fruition. Imo there's no other synth plugin development anywhere near as exciting as this

[mystran]

All these things make a cheap 1:1 translation much more complex or impossible in some situations.

Thanks for the clarifications. As I hopefully pointed out in my original post I'm not familiar with the DSP architecture, so I was just curious, 'cos a different word-size on it's own just didn't sound like a reasonable source of slowdown.

[EvilDragon]

Yeah, I didn't know ALL those details so I couldn't provide them

[xhunaudio]

...it gets more and more interesting over time...

[numerouno]

JIT status update: Most of the instructions are now implemented, enough to switch over to the process of building blocks of JITted code to execute them

[xhunaudio]

Hi numerouno,

I have the impression you are focusing on the Virus B and C for the first versions of the DSP563XX emulator.

Once a first version of the emulator will be out, how much difficult will be to add compatibility with other single-DSP devices (the Microkorg or MS2000 roms for example) ? Except for the GUI design...

[EvilDragon]

Next up after Virus C is Waldorf Microwave II/XT and microQ.

[Shiek927]

Once a first version of the emulator will be out, how much difficult will be to add compatibility with other single-DSP devices (the Microkorg or MS2000 roms for example) ? Except for the GUI design...

I'm curious actually as to how many chips the Microkorg and MS2000 has. I'm assuming the Microkorg has one, but I'm assuming the MS2000 has several more?

[xhunaudio]

Microkorg and MS2000 are exactly the same system, but in 2 different boxes - except for the sequencer steps number (8-16) if I remember correctly (?)

The order in which new roms will be introduced is not important for me (Waldorf ones are great too), I was just asking about *how much difficoult* is the whole process of adding compatibility with a single new rom (on average, excluding the new GUI design).

[Shiek927]

Microkorg and MS2000 are exactly the same system, but in 2 different boxes - except for the sequencer steps number (8-16) if I remember correctly (?)

Dang, just one? that's actually really impressive considering how great they sound

[numerouno]

Once a first version of the emulator will be out, how much difficult will be to add compatibility with other single-DSP devices (the Microkorg or MS2000 roms for example) ? Except for the GUI design...

This is very hard to estimate as every machine is very unique.

The first goal is to have the ROM. Next is to have the machine specifications in as much detail as possible. Perfect would be to have a service manual / schematics. High resolution photos of the PCB are useful, too.
Best case is if someone owns the device and knows how to use a bus analyzer

It can be quite complex to analyze a ROM as it does not only contain DSP code, but also Microcontroller code. While the DSP usually does all the audio processing, the uC reads the front panel knobs, draws the LCD if applicable, reads/writes to the MIDI ports etc.

One have to know that a DSP does not have access to the ROM at all, the only memory that the DSP has access to is RAM, whose contents are lost when you turn off the machine. To load the DSP program, the uC sends it to the DSP at boot via serial interface and this step needs to be recreated, too. Usually the DSP code is packed and needs to be unpacked first. On the Virus C, the DSP is the one that unpacks its own code.

Once that has been done, the communication between the uC and DSP while being operated needs to be analyzed too.
And this can vary a lot between different machines. For example, the Virus C DSP code more or less understands MIDI directly. The uC controller just forwards packets from/to MIDI ports. But this might not be the case on other devices. Right now it turns out that there is a lot of communication between the uC and the DSP on the Waldorf Microwave II/XT, probably to change Wavetables. Not sure yet.

To sum this up, emulation for each additional hardware requires quite a bit of research. At least, it varies quite a lot between manufacturers. After we were able to execute the Virus C ROM, we loaded the Virus B ROM because we were curious and it worked out of the box.

In contrast, the DSP emulation itself does not require lots of research at all, as everything is very well documented, is generic (only differs very slightly between different devices), challenges are very different there and are programming/optimization related. But in general, improvements made to the DSP emulation makes all emulated devices benefit.

What can be said though is that with every new synthesizer being finished, others will become easier as you usually can build on existing knowledge and/or code.