Update 2#: my virtual WING (running the real firmware) now makes sound, with EQ and compression, slowly
Follow-up to https://www.reddit.com/r/livesoundgear/s/htqXGb10zX about a software WING that runs the console’s own firmware (WING Rack 3.1.1) instead of a re-creation of it. The goal is still a real virtual sound check at home: play back a multitrack recording through the actual WING’s processing on my PC, and mix it on the console’s own interface.
Last time I ended with a list of what didn’t work. Here’s where those stand:
- No audio → it plays sound now. Audio goes through the console’s own emulated input and bus DSPs and out of MAIN 1 on my speakers. My Scarlett comes in as local inputs (didn't show in the video), and a WAV loops on USB 1/2 (in the video).
- When I move a fader on WING Edit, the firmware itself writes the new value into the DSP that’s making the sound.
- Which channel hears which source comes from the firmware’s own routing.
- EQ and the compressor work too. Changing them on the console’s screen changes what I hear, because the console’s own EQ and dynamics run on the emulated input DSP.
- No network → WING Edit connects. The console answers discovery, and WING Edit talks to it like a real WING.
- About a third of real time → the console runs at about half real time. The audio DSPs run at about 0.6×, and that’s the catch: the sound has gaps. The audio itself is correct (an offline render of the same DSP state comes out clean); there just isn’t enough of it per second yet.
One thing to know while watching: when I click out of the command window (the emulator runs from there and isn't shown in the video) into the browser to change something, the sound gets noticeably worse: more gaps and more crackle. That’s not the EQ or the compressor doing it; it happens just by switching windows. Windows gives the window you’re using more CPU time than background ones, and the emulator is already short on speed. Most likely it loses just enough when it’s in the background to get worse. With the command window focused, it’s only gaps.
What’s still missing:
- Speed. Each DSP runs on one CPU thread flat out, while the rest of the CPU sits mostly idle. The next step is spreading each DSP’s work over more cores.
- The FX DSPs in the live path. They boot and run, but FX inserts are silent live for now.
- The XMOS and the FPGA’s audio side still aren’t emulated. My own code moves audio in and out of the DSPs where the FPGA would, and it takes the routing from the firmware itself.
- No comparison against a recording from a real WING yet.
The setup is the same as before. The i.MX6 ARM application runs on Unicorn. The four ADSP-214xx SHARC DSPs run on an interpreter built for this project, with a C version checked against it instruction by instruction.
What’s new is that the DSPs answering the console are the same ones making the sound, each in its own process. Between blocks of audio, each one takes the console’s control messages through its own firmware, exactly as it does on the real hardware.