# Hardware platforms and profiles

> Experimental board and FM-1 targets, consumer multi-effects research, delivery paths and physical qualification limits.

Canonical: https://maru.audio/docs/hardware-platforms
Documentation index: https://maru.audio/llms.txt

The pedal workbench includes the board targets below and an experimental FM-1 instrument lane. They are build and evaluation paths; compatibility and physical qualification depend on the exact module and device. The consumer-device scope was reviewed on October 15, 2026; board evidence below retains its October 2 scope.

> **In the Help Center:** [Controllers, pedals and hardware](https://maru.audio/help/hardware-and-controllers.md) for what works with controllers and devices today.

| Target ID         | Platform                            | Delivery path                                                              | Current evidence and limits                                                                                                                                                                                                |
| ----------------- | ----------------------------------- | -------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `linux-pi5`       | Raspberry Pi 5, Linux ARM64         | Effect `.so` and resident audio/MIDI service; SSH install/rollback tooling | Cross-build and host-native audio/MIDI checks exist. ALSA, install, timing and recovery have not been exercised on a Pi. Static realtime audit failures remain.                                                            |
| `rp2350-pico2`    | Raspberry Pi Pico 2, Cortex-M33     | Linked firmware, UF2 through USB BOOTSEL; CDC telemetry                    | Firmware builds and QEMU checks exist, including USB-MIDI effects. Audio needs the profile's external codec wiring. Memory and realtime fit are per module. No physical-board qualification.                               |
| `daisy-seed-h750` | Daisy Seed, Cortex-M7               | Linked firmware through USB DFU; CDC telemetry                             | Firmware builds and QEMU audio checks exist. SRAM/SDRAM placement is recorded in the build. MIDI effect mode is absent. No physical-board qualification.                                                                   |
| `esp32-s3`        | ESP32-S3-DevKitC-1 N8R8, Xtensa LX7 | ESP-IDF firmware/ELF, serial flashing and telemetry                        | Experimental canonical Processor export and Espressif QEMU checks. Proposed ADC/switch, isolated UART MIDI and external duplex I2S wiring. PSRAM fit does not establish realtime capacity; physical qualification pending. |
| `fm1-ac791n`      | M-VAVE FM-1, JieLi pi32v2           | AC79 firmware and .fwsc packaging; USB-MIDI SysEx installer tooling        | Alpha build/simulation path. Packaging requires verified USB/update HAL and a loader. Memory, realtime fit and physical install/restore/recovery remain open.                                                              |

A Raspberry Pi 5 package and a Pico 2 UF2 are different artifacts. Selecting a board profile determines the build and transport; it does not grant compatibility by itself.

## Fit is a property of a module and a board

[Guitarabin](https://maru.audio/modules/guitarabin) illustrates why this matters: its current MCU instance needs about 874 KB of state, exceeding Pico 2 SRAM. It builds for Daisy with external memory, but emulated processing exceeds its indicative CPU budget. Compiler lowering of 64-bit arithmetic is one active performance issue.

Small MIDI transforms can be useful earlier: MIDI Transpose and Chorder have Pi and Pico 2 build/emulation paths. They still require device MIDI, timing, stuck-note and recovery tests before a supported release.

A multieffect can be expensive even when most slots are disabled. The current [Multifx](https://maru.audio/modules/multifx) implementation prepares state for many algorithms; an October 1 source-state scan found 12,186,204 bytes of typed-array backing storage at 48 kHz, before objects, generated adapters and runtime overhead. Choosing phaser and distortion on its face does not reduce that allocation. A smaller hardware configuration needs a change in the canonical module/shared engine, then fresh state and sound verification.

## Platforms under investigation

The [hardware summary](https://maru.audio/hardware#consumer-hardware) compares M-VAVE device families and links to primary evidence. FM-1 has community replacement firmware; SMK-37 Pro/Elite have their own author-published firmware. Neither establishes a qualified Maru release. FM-1 images are not interchangeable with SMK-37 images.

ANN Blackbox has BLE/USB protocol and firmware research; MK-300 has community USB control tools. TANK and CUBE BABY families have vendor editors and selected community preset tools. Editing presets, importing IRs or supported amp models, and updating vendor firmware do not establish arbitrary compiled-code loading. This review establishes no Maru firmware target for these multi-effects units.

The toolkit direction is exact-device detection, backup/recovery, a board-specific audio/control adapter, compilation and fit checks, then verified packaging and installation. FM-1 tooling exists; extending it to another product requires its own hardware evidence, not just the same updater app.

Elk Audio Stomp/Jackpot and Roland/Lydia have integration studies and earlier packaging experiments. They are not target producers in the current pedal workbench. Their plugin/runtime and vendor integration paths need separate qualification. Other boards require an explicit profile and adapter; a similar CPU is insufficient evidence.

## What a profile means

A profile describes the intended architecture, audio layout, rate and block constraints, logical controls, display and deployment requirements. Development profiles can describe a virtual control surface. They do not prove that pins are wired, a codec works or a timing budget is met.

On the device, record the exact board revision, codec, firmware/OS, clocks, memory placement, controls and artifact hash. Then measure processing cycles, xruns, round-trip latency, noise/clipping, MIDI behavior and recovery. The target is qualified only for the tested configuration and module release.

See [Hardware architecture](https://maru.audio/docs/hardware-architecture.md) for the host relationship and [From module to hardware](https://maru.audio/docs/from-module-to-hardware.md) to start an evaluation.
