A MIDI chord pedal and an audio harmonizer ask very different things of a board. The first needs reliable event handling and controls. The second needs continuous audio, enough working memory and a processor that finishes every block before the next one arrives.
Our starting shortlist is Daisy, Teensy 4.x, ESP32-S3, Raspberry Pi Pico 2 and Raspberry Pi 5. These are practical choices with documented development ecosystems, rather than a ranking by sales or pedal-maker market share. We have not found comparable market-share data that would justify naming one the most popular.
For an audio-first prototype, our first candidate is Daisy with its onboard audio hardware. For a compact MIDI effect or controller, Pico 2 is a useful starting point. ESP32-S3 deserves an evaluation when its I/O, available memory variants or connectivity suit the product. Teensy 4.1 is an attractive next adapter candidate. A Pi 5 makes sense when the project needs a Linux computer and substantially more memory. These are engineering recommendations; Maru compatibility still depends on the exact board, module and measured configuration.
The boards worth comparing
| Platform | Hardware starting point | Best reason to evaluate it | Work still needed for a pedal |
|---|---|---|---|
| Daisy Seed, original STM32H750 model | Cortex-M7 up to 480 MHz; onboard stereo 24-bit audio hardware up to 96 kHz; optional 64 MB SDRAM | An audio-oriented platform with fewer codec decisions during bring-up | Instrument-level input/output circuitry, pedal power, controls, enclosure and qualification |
| Daisy Seed3 | Cortex-M7 at 480 MHz; 65 MB RAM; onboard stereo audio hardware up to 192 kHz/32-bit | A newer audio platform to assess for a fresh design | A separate codec/board qualification; our original Seed adapter does not establish Seed3 support |
| Teensy 4.0 / 4.1 | Cortex-M7 at 600 MHz; 1 MB internal RAM; 4.1 adds accessible expansion options | PJRC's audio library, MIDI facilities and audio adaptor ecosystem | An audio adaptor or codec, analog/power design and a Maru target adapter |
| ESP32-S3-DevKitC-1 N8R8 | Dual LX7 cores up to 240 MHz; 512 KB internal SRAM; this module variant has 8 MB flash and 8 MB PSRAM | Flexible controls and interfaces, with a concrete Maru export/emulator study now available | External audio converters, memory-placement decisions and physical audio/MIDI tests |
| Raspberry Pi Pico 2 | RP2350 at 150 MHz; 520 KB SRAM; 4 MB flash | Small MIDI utilities, controllers and bounded effects | External audio converters for an audio pedal; careful state and CPU budgets |
| Raspberry Pi 5 | Quad Cortex-A76 at 2.4 GHz; gigabytes of RAM; Linux | Large state, storage, networking and applications needing an operating system | An audio interface, scheduling and boot/recovery design, power and cooling |
Specifications above are manufacturer capabilities, not our measured throughput. References: original Daisy Seed, Seed3, Teensy 4.1 and 4.0 comparison, ESP32-S3 datasheet, DevKitC-1 variants, Pico 2 and Pi 5.
Check the exact SKU before ordering. The original Daisy Seed's 1 MB version omits the external SDRAM; the 65 MB version includes it. A firmware configuration using SDRAM needs the corresponding board. Daisy's memory guide explains the distinction.
PJRC's standard Audio Library and adaptor path uses 16-bit, 44.1 kHz streaming. That is a useful established environment, but a fair comparison with our 48 kHz fixtures requires a deliberately matched configuration. We cannot infer a 48 kHz Maru result from the library's examples. Teensy Audio Library
Also consider Arduino GIGA R1 and STM32 development boards when their form factor or peripherals fit the product. Arduino documents GIGA's audio-oriented examples and DAC facilities, but those do not make a complete stereo input/output pedal. Each board still needs its own audio design and host adapter. Arduino GIGA R1 documentation
Choose the whole pedal, not just the processor
Our recommendations above follow the integration work each project needs. Compare the complete bill of materials: board, converters, instrument input buffer, output stage, power regulation/protection, MIDI interface, controls, connectors and enclosure. Check current supplier prices for that assembly, rather than comparing the cheapest bare-board listing with an audio development kit.
Onboard line-level audio is helpful, but a passive guitar pickup needs the appropriate input impedance and headroom. Decide how bypass behaves, what happens on a crash or power loss, and how firmware updates recover. Include noise, clipping and control response in the acceptance criteria.
Memory needs depend on the algorithm. A delay line, pitch shifter or harmonizer can need much more state than a gain stage. External SDRAM and PSRAM can make an algorithm fit, but access costs, DMA constraints and numerical work still affect whether it finishes on time. Two cores do not automatically double the throughput of one sequential audio callback.
What Maru can export today
As of this October 2 development run, the pedal workbench registers four experimental target producers: Linux ARM64 on Pi 5, Pico 2 Cortex-M33, original Daisy Seed STM32H750 and ESP32-S3. Teensy, Seed3, other STM32 boards and Pico's RISC-V mode are not current Maru target producers. The hardware platforms guide owns the current support scope and per-target limitations.
The workbench exports a board-specific shell around a module's canonical Processor. Its MIDI events, parameters and DSP come from the same module project used by other hosts. The hardware shell supplies startup, transport and controls; it does not substitute a simpler sound engine to make an export pass.
Export, emulation and physical qualification are separate results. None of these four lanes has a physically qualified release recorded in this snapshot. A linked image or passing emulator fixture does not establish that the codec, USB/UART transport, controls or realtime budget work on a real pedal. Start with From module to hardware for the evaluation workflow.
Our first ESP32-S3 measurements
We built the canonical Chorder MIDI effect and Harmonizer audio effect for the DevKitC-1 N8R8 development profile. The run used ESP-IDF v5.5.1, pinned to commit fcae32885b0296b32044cb99ecbdc50d98dddb83, and Espressif QEMU esp_develop_9.2.2_20260417, configured with 8 MB flash and 8 MB octal PSRAM. The firmware export's default block size was 64 frames; the emulator fixtures swept 16, 32, 64 and 128 frames at 48 kHz.
These are measured build sizes, emulated arena use and functional checks. Physical callback time, round-trip latency, electrical audio quality and soak reliability remain unmeasured. QEMU wall-clock duration measures how long the test took on the development computer; it is not an ESP32-S3 CPU benchmark.
| Module | Firmware app image | Prepared arena in emulation | Functional result at all four block sizes |
|---|---|---|---|
| Chorder | 430,304 bytes | 59,604 bytes | All nine canonical MIDI scripts passed; exact emitted-event parity with the generated host reference |
| Harmonizer | 459,264 bytes | 696,344 bytes | Exact raw float32 output checksum 0x7b8635a2; block-size consistency and audio health passed |
App image sizes exclude bootloader, partition table and debug ELF. Arena use is not total RAM use: it excludes other buffers, task stacks and ESP-IDF/transport overhead. The emulator test image and physical-I/O firmware image are separate builds of the same module source. Harmonizer's measured arena is PSRAM-resident and already larger than Pico 2's total internal SRAM.
The tested fixtures reported zero process failures, event overflow, non-finite audio and realtime allocation attempts. Harmonizer's rendered left/right peaks were −10.82/−15.28 dBFS and RMS levels were −19.24/−24.31 dBFS, with no clipping. Those levels describe digital fixture output, not measured analog converter levels or worst-preset behavior.
Inspect the saved reports
These frozen copies retain the existing workbench run format, source revisions, checks and artifact hashes:
- Chorder: firmware build report and emulator report.
- Harmonizer: firmware build report and emulator report.
The reports' artifact paths identify local build outputs; they are not public firmware download URLs. Their elapsedMs fields are stage execution duration, not per-block processing time. The firmware app SHA-256 values are:
Chorder 62896fa887f0199382bdd5365c7d95aad7e028225f830cb25b3ca592a5bda034 Harmonizer 4f9aeaa04ddbb8f97d574ffa8dc9dc9f0ee7f9b66ce8e982926b82c3a66b85b5
S3's FPU handles single-precision arithmetic, while current generated JavaScript-number arithmetic includes software double operations. Together with PSRAM access, that makes physical timing a necessary next test. Harmonizer remains a demanding feasibility study; this result does not promise a playable S3 harmonizer.
A benchmark that helps choose a board
We will use the same source revision, preset, input fixture and sample rate across boards, while recording the compiler, optimization flags, codec, clocks and memory placement. Begin with pass-through, a matched C gain reference and the generated gain module. Then test Chorder and Harmonizer, preserving their authored behavior.
At 48 kHz, the process deadline for each block is:
| Block frames | Available time |
|---|---|
| 16 | 333.33 µs |
| 32 | 666.67 µs |
| 64 | 1,333.33 µs |
| 128 | 2,666.67 µs |
This is a scheduling budget, not round-trip audio latency. Publish p50, p95, p99 and maximum callback time, cycles where available, memory high-water marks, underruns and failures. Measure the complete I/O schedule as well as the DSP window. Keep onset, reset, parameter changes and worst presets in the workload.
Our proposed initial gate is p95 at or below 70% of the callback budget, maximum below 100%, and zero observed deadline, I/O or invalid-output failures. It leaves room for other work and still needs a physical stress run. Passing a finite run cannot prove that a deadline will never be missed.
For Chorder, stress chord/note density, strum timing, latch/release, panic, saturated MIDI and reconnect behavior. Check for dropped events and stuck notes. For Harmonizer, test silence, impulses, clean and noisy leads, chord changes, all voices and demanding presets. Measure algorithm delay separately from codec and buffering delay.
Finish with physical audio/MIDI loopback, calibrated headroom and noise tests, control sweeps, power-cycle/recovery checks and at least a ten-minute soak with controls and MIDI active. Until those runs exist, our result table has no physical performance winner.
From a profile to wiring and a schematic
The S3 profile describes four pots, a footswitch, isolated serial MIDI and a proposed external stereo I2S input/output path using PCM1808 and PCM5102A breakouts. The workbench's Design → Board connections view generates the pin table, SVG connection diagram and JSON netlist from that profile and the project's actual parameter bindings.
Those files describe a development connection proposal. A production pedal still needs the converters' supplies and straps, input/output conditioning, grounding, power protection and PCB review. The connection drawing ends at the codec and MIDI driver interfaces. It does not validate the analog circuit.
Our next physical comparison should start with the original Daisy Seed with SDRAM, Pico 2 and the exact ESP32-S3 N8R8 board because their export lanes already exist. Add a Teensy 4.1 adapter as a subsequent comparison candidate, and assess Seed3 as a separate board/codec revision. Keep Pi 5 in the comparison for designs needing Linux. Each published result will identify a module release and a complete tested configuration, so a pedal maker can judge the evidence against the instrument they want to build.
