Platform index

A nine-processor console whose mixing DSPs have no instruction memory at all — the audio path is fixed-function silicon configured through a register file.

Nine years newer than the QL and sharing almost nothing with it but the parameter framework — and, crucially, the same DSP philosophy: the signal path is fixed-function on both, however different the host looks. In 2026 the entry gained a second axis the firmware analysis never touched: the DM3's live **control plane**, captured and driven against a real console -- the first hardware any part of this entry rests on.

Not one console CPU but a small cluster of identical i.MX8M Mini computers running one Linux rootfs in four roles — and the only platform here that ships its entire mixer parameter model as plain XML.

A 55 MB firmware image that contains none of the mixer. The audio path lives in FPGA fabric behind an undocumented AXI register map — and the fabric has now been opened far enough to read a pan-law table out of it.

The structural inverse of the SQ: the control plane is a commodity x86 Linux box, and the mixing runs on a subordinate Xilinx FPGA the host programs at boot. OS updates carry integrity checksums but no signature.

The 2nd-generation Qu is SQ silicon in a Qu suit, and not by analogy — it is the same Zynq part, running a mix bitstream of the same size, with the SQ's boot BSP and the Avantis's FX subsystem.

The original Qu is a 2014 multi-chip embedded design — an NXP Cortex-M control MCU, an Analog Devices Blackfin audio DSP and an FPGA — with every processing block included and no paid-add-on lock. It shares nothing but a brand with the SQ-derived 2nd-gen Qu.

A&H's in-house replacement for the Audinate Brooklyn II Dante module, codenamed KLANTE: a Xilinx Zynq-7010 running embedded Linux that hosts Audinate's Dante IP core. It is the one A&H firmware in this index that is cryptographically signed.

The install processor whose control surface is half published. Allen & Heath document levels, mutes, routing crosspoints, preset recall and source selection — and nothing at all for EQ, delay, dynamics or metering. The other half lives in System Manager's own protocol and in its configuration files, and only the files have been opened.

The 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.

The only platform here being studied to build on rather than to understand — and the only one where the container format was analysed, found opaque, and then declared off the critical path.

Not a console, but the transport a great many of them hang off. Documented from both ends at once — the server firmware and the host driver are the same protocol version.

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.

Not a teardown. The open console these teardowns keep pointing at — included because "what would you build instead" is the question every one of them ends on.

Still essentially unexamined as a console — no firmware package, no silicon, no update path. What has been looked at is what its Director application writes to disk, and that turns out to be the Avantis format.

The container is solved to the byte and every payload inside it is encrypted — so the update image is simultaneously the most transparent and the least readable in this index. It is also the only platform here where a third-party project runs its own operating system on the hardware.

Six models, one firmware, one set of bitstreams. The layer engine lives in FPGA fabric that is configured identically on every unit in the range, so the tier a machine sells as is decided by an integer it reads at boot.

A card frame with an x86 PC inside it and a microcontroller on every card. Layer count is not a setting — it is how many processing cards are in the chassis.

A COM Express Xeon-D module driving a card frame of Intel Arria 10 GX FPGAs, one microcontroller per card. The RS models are fixed card lists; the C models are the same chassis sold configurable.

A decade of vision mixers that are all the same idea: a Xilinx FPGA does the video, and a CPU inside that FPGA runs a bare-metal control stack. The CPU changes generation to generation (PowerPC, then MicroBlaze, then ARM) and so does the fabric under it — Virtex-5, Virtex-6, Kintex-7, Zynq — but the FPGA-does-everything shape never does.

A conference platform that is closed on the inside and unusually generous on the outside: every application payload in the access point is encrypted, while the control interface is plain ASCII on an open port that pushes a report every time anything changes.

A range sold as one family that is really three platforms. Every converter in it is FPGA-based — Zynq-7000 on the 1080p line, Zynq UltraScale+ with a hard video codec unit on the 4K line — except the decode-only PLAY, which has no programmable logic at all and is an ordinary Rockchip applications processor running Debian.

A receiver whose documented control interface is plain ASCII on a TCP port — and which, mounted on a Yamaha console, does not use it. The console-mount path is standards-based ACN, discovered on a multicast group one digit off the registered one and driven entirely by subscriptions.

The G3 rack receivers are remote-controlled — but not by the ASCII "media control protocol" Sennheiser published. That one (UDP 53212, firmware ≥ 1.7.0) drew silence from our EM 500 G3 on every probe. What actually drives it is an undocumented binary protocol that Wireless Systems Manager speaks on UDP 8133, and once we had it we mapped the receiver's analog output level to a console's remote head-amp gain and drove one from the other on the bench.