Platform index / Digital mixing console
Violet Audio dMix 128
A headless FPGA console that splits its work across three silicon tiers — a Zynq UltraScale+ running full Ubuntu for control, and a pair of dedicated Spartan-7 FPGAs doing the actual mixing — with an update package that quietly names the OEM behind the brand.
The load-bearing finding. The v1.2.3 update unpacks to ten arm64 Debian packages plus the FPGA images. The mixing engine is not the host SoC's fabric but two separate Spartan-7 XC7S50 devices (`mixer128_main.bit`, `mixer128_aux.bit`, Vivado 2025.1), each booting from its own SPI-NOR flash; the Zynq UltraScale+ is the Ubuntu host and the effects run on it via a separate DSP server.
Verdict. The most computer-like entry in the index, and the most tiered: an Ubuntu host on a Zynq UltraScale+ hands the mixing math to two dedicated Spartan-7 FPGAs and keeps the effects for itself, all shipped — bitstreams, web GUI and RSA-signed installer — in one update. The teardown's real payoff is naming the OEM the brand doesn't: DSPRO Audio and George Yohng.
Method
Static analysis of the single `dmix128_1.2.3.7045c05.dmixfw` update package — parsing the installer ELF, decrypting and unpacking its payload, reading the resulting package control metadata, the mypyc-compiled Python driver layer, the FPGA register-map JSON and the bitstream headers — cross-checked against the vendor's front-panel photo. No console was involved and no hardware was inspected.
Artifacts examined
dmix128_1.2.3.7045c05.dmixfw— 70 MB update package (a stripped aarch64 ELF installer stub with an encrypted payload appended)- Ten
arm64.debpackages:dsmix,fxserver-zynq,mixer-web,mixer-extcontrol,mixer-local-gui,mixer-upgradedaemon-ng,nmos-bridge,button-monitor,xilinx-prog-zynqmp, plus stockavahi-utils mixer128_main.bit/mixer128_aux.bit— Spartan-7 XC7S50 bitstreams;dsmix_zu3.bin/dsmix_zu5.bin— ZynqMP boot/PL imagesDriver/Profiles/mixer128andmixer64JSON DSP register maps;Driver/misc/*.pyhardware drivers; the vendor front-panel line-art
No manufacturer firmware, binaries or documentation are redistributed here. Artifacts are referenced by name and version only. See themethod and legal statement for the basis on which this analysis was performed and the boundaries it observes.
Hardware architecture
| Item | Finding | Confidence |
|---|---|---|
| Host SoC | Xilinx Zynq UltraScale+ MPSoC (quad Cortex-A53) running the control software; the installer branches on a device-tree device_id of zu3eg or zu5eg, and its programmable logic is loaded from dsmix_zu3.bin / dsmix_zu5.bin for I/O and interconnect | Verified |
| Model / SoC pairing | Read as the smaller ZU3EG serving dMix 64 and the larger ZU5EG serving dMix 128 (both boot images ship together) | Inferred |
| Mixing DSP | Two dedicated Xilinx Spartan-7 XC7S50 FPGAs — the bitstream headers name mixer128_main and mixer128_aux, part 7s50csga324, Vivado 2025.1. Each boots from its own SPI-NOR config flash and is addressed by a CORE_ID / fpga_sel selector; the host reprograms them over SPI | Verified |
| Effects DSP | The FX rack (reverb, delay, chorus, a DX480-style processor) runs on the host via fxserver-zynq, separate from the Spartan-7 mixing cores | Inferred |
| Converters & clocking | AKM AK5558 8-channel ADCs and AK4454 DACs in I²C-addressed slots, carried to the fabric over TDM. Renesas VersaClock 6E master generator (I²C, OTP-programmed); network clock recovered by a software DPLL | Verified |
| Physical I/O | 3U front-I/O stagebox: 32× XLR mic/line in (phantom + head-amp), 24× XLR out, 2× AES/EBU in+out, 2× ¼" phones, MADI in/out on BNC coax, a CONTROL etherCON and redundant dNet A/B etherCON (AES67, copper), DisplayPort video for the local GUI, USB-A + USB-C (with USB-PD), one option-card slot, dual redundant PSU | Verified |
Software architecture
| Item | Finding | Confidence |
|---|---|---|
| Operating system | Ubuntu 24.04 aarch64 userland under systemd (packages built with GCC 13.3, Ubuntu 24.04) | Verified |
| Makers behind the brand | Package maintainers are DSPRO Audio (dspro.com.br) for the platform integration and George Yohng (yohng.com) for the mixer core — Violet Audio is the brand | Verified |
| Mixer application | dsmix is mypyc-compiled Python: a Driver/ hardware-abstraction layer plus JSON register/routing maps for both mixer128 and mixer64 profiles, driving the Spartan-7 cores. fxserver-zynq is the host-side FX server | Verified |
| Control plane | mixer-extcontrol (Go) serves the external protocols — ECP (Q-SYS), QRC, the zero-based VSKP keyspace and OSC — plus a Socket.IO/WebSocket layer on port 80. It additionally embeds an MCP/LLM "assistant" with an instrument-EQ preset knowledge base | Verified |
| Media control | nmos-bridge re-exposes the console as AMWA NMOS IS-04/05/08 senders and receivers (Python, Nuitka-compiled standalone) | Verified |
| Update mechanism | A Go upgradedaemon performs btrfs-snapshot A/B "checkpoint" upgrades — installing the packages, updating kernel and boot artifacts, and able to roll back to the previous snapshot | Verified |
Update path & security model
| Item | Finding | Confidence |
|---|---|---|
| Update confidentiality / integrity | The .dmixfw payload is AES-256-CBC encrypted with a SHA-256 integrity check; the installer stub links OpenSSL and decrypts the payload to a temporary archive before unpacking | Verified |
| Update authenticity | Each package and the outer payload carry a 256-byte RSA-2048 signature; the upgradedaemon embeds an RSA-2048 public key and the signature-verification path is present in the binary | Verified |
| Recovery | The btrfs A/B checkpoint model provides rollback to the prior known-good snapshot if an upgrade is rejected or fails | Verified |
These rows describe how a platform validates a firmware image, because that is a structural fact about its architecture. They are not a vulnerability disclosure and no exploit, bypass or circumvention technique is published here. Licensing and entitlement mechanisms are out of scope throughout — seescope boundaries.
What is programmable
- 1The mixing engine is two Spartan-7 bitstreams
`mixer128_main.bit` and `mixer128_aux.bit` configure a pair of XC7S50 DSP FPGAs from their own SPI flash; the audio path is defined by programmable logic and the JSON register maps in `dsmix`, not by fixed silicon — the direct contrast to the Yamaha QL entry, but with the DSP split off the host SoC entirely.
- 2Zero-based VSKP keyspace over `mixer-extcontrol`
Dot-delimited keys such as `i.0.eq.b1.freq`, with `*` matching one component and `**` many. The same daemon also exposes ECP (Q-SYS), QRC, OSC and a Socket.IO layer.
- 3MCP/LLM control
`mixer-extcontrol` ships an agent that drives the console over MCP tools using an instrument-EQ knowledge base — an LLM-facing control surface baked into the firmware.
Traps
Mistakes this analysis actually made, or came close to making. They are recorded because each one produces a plausible-looking wrong answer rather than an obvious failure.
- The
.dmixfwis not an archive — it is an executable installer with an encrypted payload appended after the ELF section headers, so ordinary archive tools see only a stripped binary. - The bitstreams target part
7s50csga324— a Spartan-7, not the Zynq's own fabric; the mixing DSP is separate silicon from the host SoC, which is easy to misread as the SoC's PL.
Open questions
- Exactly how the `main` and `aux` Spartan-7 cores divide the channels and buses between them.
- How much mixing runs in the Spartan-7 pair versus the Zynq PL versus the `fxserver-zynq` process.
- Nothing here was checked against a running console; all findings are from the update package and public images alone.
Status of this entry. A written teardown exists and its claims carry evidence citations. Unless a row says otherwise, nothing on this page has been verified against physical hardware.