Stoatworks Labs · research
How digital mixing consoles are actually built
Independent teardowns of the platforms behind live-sound consoles — derived from published firmware, service manuals and datasheets, with every claim labelled by how well it is evidenced. No console was opened. Nothing here has been tested on hardware.
Browse the platform index → · Read the method & legal statement
The question this started from
We build audio processing software — equal-loudness EQ, zero-latency dynamics, sound level measurement. Each of those raised the same obvious question: could this run on a console? Answering it honestly meant finding out what is inside the consoles, which turned out to be a considerably more interesting question than the one we started with.
The short version is that the industry has quietly split into two architectures. On one side are platforms where the mixing is fixed-function silicon or FPGA fabric, and the megabytes of firmware you can download contain none of the audio path at all. On the other are platforms running a conventional operating system where the DSP arrives as a loadable image. The difference is invisible from the front panel and decides everything about what a third party could ever do with the machine.
Two of the four teardowns concluded "no". That is the useful part. A negative result reached with evidence — these DSPs have no instruction memory, and here is the absence that proves it — is worth more than an optimistic maybe, and it is recorded here as prominently as anything else.
What each entry records
| Section | What it answers |
|---|---|
| Hardware architecture | The real silicon — SoC, mixing DSP, FPGA, converters, memory, panel MCUs, network — with the evidence for each part number. |
| Software architecture | Operating system or lack of one, core model, load addresses, task structure, what fraction of the image is actually code. |
| Update & security model | How firmware is packaged, and how the device decides an image is acceptable. Structural facts, not exploits. |
| What is programmable | Ranked, honestly. Often the answer is "not the part you wanted". |
| Traps | Mistakes the analysis made. Each one produced a plausible wrong answer rather than an obvious failure. |
| Open questions | What remains unknown, stated as plainly as what is known. |
Platforms examined
Yamaha QL1
Digital mixing consoleA nine-processor console whose mixing DSPs have no instruction memory at all — the audio path is fixed-function silicon configured through a register file.
Yamaha DM3
Digital mixing consoleNine years newer than the QL and sharing almost nothing with it but the parameter framework — including, crucially, the same DSP philosophy.
Allen & Heath SQ-5
Digital mixing consoleA 55 MB firmware image that contains none of the mixer. The entire audio path lives in FPGA fabric behind an undocumented AXI register map.
Midas HD96
Digital mixing consoleThe one console examined whose control plane is wide open: a full Linux computer speaking documented Thrift and Protobuf. The mixer still lives in FPGA fabric — but the bitstreams ship in the clear and the exact parts are known.
How to read this
Every row in every table carries a confidence label:Verified means it was read directly out of an artifact; Inferred means it is a well-supported reading of evidence with the competing readings given;Unknown means the artifacts show it exists and nothing more; Public means a datasheet or standard said so and no analysis was needed.
The labels are the point. It would be easy to write this site in a confident voice and much less useful. Where something rests on a single artifact, or on an image no longer in our possession, the page says so.
Before citing anything here, please read themethod and legal statement — it sets out how the work was done, the boundaries it observes, and what it deliberately does not touch.