Platform index / Digital mixing console
Violet Audio dMix 128
A headless FPGA console whose mixing DSP is reconfigurable programmable-logic fabric loaded at every boot, running a full Ubuntu userland on a Zynq UltraScale+ MPSoC — and whose update package quietly reveals the OEM behind the brand.
The load-bearing finding. The v1.2.3 update is a self-decrypting installer that unpacks to ten arm64 Debian packages. Their maintainer fields name the real makers — DSPRO Audio of Brazil for the platform, and audio developer George Yohng for the mixer core — while the payload ships the two Vivado bitstreams (`mixer128_main.bit`, `mixer128_aux.bit`) that ARE the mixing engine, loaded onto the PL through the Linux fpga_manager.
Verdict. The most conventional computer in the index: a signed-and-encrypted Ubuntu appliance on a Zynq UltraScale+, where the mixing "hardware" is a bitstream shipped inside the same update as the web GUI. 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, and reading the resulting package control metadata, hardware-driver Python, FPGA register-map JSON and boot artifacts. 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— Vivado FPGA bitstreams;dsmix_zu3.bin/dsmix_zu5.bin— ZynqMP boot imagesDriver/Profiles/mixer128andmixer64— JSON DSP register/routing maps;Driver/misc/*.py— hardware drivers
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 |
|---|---|---|
| SoC | Xilinx Zynq UltraScale+ MPSoC (quad Cortex-A53 + programmable logic). The installer branches on a device-tree device_id of zu3eg or zu5eg | Verified |
| Model / SoC pairing | ZU3EG and ZU5EG boot images ship side by side (dsmix_zu3.bin / dsmix_zu5.bin); read as the smaller ZU3EG serving dMix 64 and the larger ZU5EG serving dMix 128 | Inferred |
| Mixing DSP | Reconfigurable FPGA fabric — two .bit bitstreams (main + aux) programmed onto the PL at boot via the mainline fpga_manager (/sys/class/fpga_manager/fpga0/state). No fixed-function mixing silicon | Verified |
| Clocking | Renesas VersaClock 6E generator, OTP-programmed over I²C by an in-tree driver | Verified |
| Board support | ADS1x15 ADC, PCA9536 GPIO expander, FTDI link and SPI NOR flash, driven from Python; hardware revision read from ZynqMP GPIO | Verified |
| Audio I/O | 96 kHz throughout; 32 head-amps, 32 AD / 28 DA, 2 AES3, 64 MADI, and 384 network (Dante/AES67) channels in the fabric map | 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. fxserver-zynq is the FX/DSP server against the fabric | Verified |
| Control plane | mixer-extcontrol (Go) serves the external protocols — ECP (Q-SYS), QRC, the zero-based VSKP keyspace and OSC — and 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 an FPGA bitstream
`mixer128_main.bit` and `mixer128_aux.bit` are loaded onto the PL at boot; 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.
- 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 and OSC.
- 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 mixing DSP has no persistent firmware image on a flash chip to dump: it is a bitstream re-loaded into volatile fabric at every boot.
Open questions
- Whether the ZU3EG/ZU5EG split maps exactly to dMix 64 / dMix 128, and what the `main` vs `aux` bitstream division corresponds to in the signal path.
- How much of the mixing math lives in the PL fabric versus the `fxserver-zynq` process, since the DSP register maps are declarative JSON.
- Nothing here was checked against a running console; all findings are from the update package 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.