DSPi Firmware for Raspberry Pi Pico Audio Processing

Why DSPi Exists on RP2040 and RP2350

DSPi addresses a specific gap between host-based audio software and a fixed hardware audio processor. It makes a Raspberry Pi Pico, Pico 2, or another RP2040-based board appear as a USB sound card, then applies configurable processing before audio reaches external digital outputs. The intended users are builders of active speaker systems, multichannel installations, headphone chains, and subwoofer integrations who need controls that are independent of the playback computer.

The processing options include parametric equalization, active crossovers, matrix routing, loudness compensation, a volume leveller, crossfeed, time alignment, per-channel gain, and output mute. DSPi can operate at 44.1, 48, or 96 kHz and accept 16-bit or 24-bit PCM through USB. Its S/PDIF input is narrower, accepting 24-bit PCM stereo at 44.1 or 48 kHz, so source compatibility depends on the selected path.

This is not presented as a general-purpose USB DAC firmware. Its value comes from placing several processing and routing stages into one small embedded endpoint. That distinction also defines its main operational cost: adoption depends on wiring external converters or amplifiers correctly, loading firmware, and finding or building software that sends the USB control commands.

DSPi USB Input, DSP Routing, and Digital Outputs

The signal begins as stereo USB audio. According to the README, DSPi presents itself as a plug-and-play USB sound card under macOS, Windows, Linux, and iOS. A per-channel preamp is applied first, providing independent L/R gain before the rest of the processing pipeline. A 2-by-5 matrix mixer on RP2040 or a 2-by-9 mixer on RP2350 can then route either input channel to available outputs, with gain and phase inversion at each crosspoint.

Processing continues through configurable stages such as equalization, crossover filters, loudness compensation, crossfeed, levelling, and delay. The README places master volume at the end of the signal chain. Its range is -128 to 0 dB, with a true-mute sentinel. It can persist independently of presets, which prevents a preset change from altering the stored master level, or it can be restored with a preset.

Outputs can switch at runtime between S/PDIF and I2S. RP2040 provides two stereo output slots, while RP2350 provides four, for four and eight output channels respectively. I2S slots share BCK and LRCLK and can produce a 128x or 256x master clock. A separate mono PDM path drives a subwoofer through a second-order delta-sigma modulator. Delay reaches 85 ms per output, and DSPi documents automatic latency compensation between S/PDIF or I2S and PDM paths.

The two processors use different arithmetic. RP2040 uses Q28 fixed-point processing and hand-optimized ARM Assembly, while RP2350 uses single-precision floating point and a hardware FPU. EQ work is divided across both cores, which is especially relevant when several outputs are active.

Filter Bank, Crossovers, and Channel Limits

Parametric EQ is the central processing block in DSPi, with up to 10 bands per input channel and 11 selectable filter types. The set includes peaking, low and high shelves, low and high pass filters, notch, all-pass, and gentler first-order variants. On RP2040, the stated ceiling is 70 total filter bands. On RP2350, it is 110. The larger RP2350 figure reflects its wider output support, not a different per-channel PEQ limit.

For multiway speakers, the crossover section provides up to four dedicated filters per output channel. Linkwitz-Riley, Butterworth, and Bessel low-pass and high-pass forms are available up to eighth order, reaching 48 dB per octave. This makes DSPi relevant to active crossover projects, although filter availability does not remove the need to choose crossover points, slopes, delays, and gains correctly.

There are hard channel limits. RP2040 provides seven total output channels: two master, four S/PDIF or I2S, and one PDM. RP2350 provides eleven: two master, eight S/PDIF or I2S, and one PDM. Projects requiring more channels need another endpoint or another DSP approach. Likewise, the documented S/PDIF input supports stereo at 44.1 or 48 kHz, not the full set of USB input rates.

Diagnostics can expose peak and clip levels, USB PHY errors, buffer statistics, S/PDIF DMA starvation, and CPU load. That instrumentation is useful during bring-up, but the README does not state whether historical measurements are retained after reboot or how alerts should be integrated into an external monitoring system.

DSPi Presets, Pin Reassignment, and USB Firmware Updates

DSPi stores as many as 10 complete DSP configurations, each with a user-defined name. A configurable startup slot determines which configuration loads after power-up. Presets can include per-channel names and, depending on the selected master-volume persistence mode, either a shared master level or a separate level per preset. The README also documents bulk parameter transfer for synchronizing device state.

Output GPIO assignments can be changed at runtime. This is important for custom printed-circuit-board layouts because I2S signals such as BCK and MCK are not locked to one fixed pin map. It does not mean arbitrary electrical routing is safe. The external converter, amplifier, ground arrangement, and signal levels still have to match the board design.

Firmware updates use a USB vendor command that reboots the device into its UF2 bootloader. The README says this lets the host application push new firmware without pressing the physical BOOTSEL button. It does not document the vendor command payload, authentication behavior, update interruption handling, or a rollback mechanism. The repository includes a firmware update command, but the presented documentation does not explain its binary structure.

This combination of runtime routing and USB updates reduces some hardware constraints. It does not remove the integration work. A host tool still has to speak the control protocol, manage successful and failed writes, and present DSP parameters clearly enough for repeatable configuration.

Building DSPi and Making the First USB Audio Pass

The README directs developers to a section named "Building from Source" for firmware construction. It also points users to the official Discord for development updates, discussion, and assistance. The available project description does not give a complete install sequence, board preparation command, toolchain invocation, or UF2 flashing command, so none is reproduced here.

The first real use begins after valid firmware has been placed on a compatible board and the required external audio hardware is connected. Connect the DSPi USB connection to the host. The operating system should enumerate the firmware's USB audio interface under macOS, Windows, Linux, or iOS. Select DSPi as the playback device, confirm that audio reaches the intended converter, and only then enable more demanding filters or multichannel routes.

Bring-up should be incremental. First verify the USB input at the selected sample rate and bit depth. Next confirm S/PDIF or I2S clocking and channel order on one output before enabling additional stereo slots. Add PDM last because it is a distinct modulator and subwoofer path. Finally, apply crossover filters and delay while watching the documented clipping, DMA starvation, and CPU-load diagnostics.

The project is described as plug-and-play at the USB audio layer, not as a zero-configuration hardware design. Board pin assignments, output standards, amplifier inputs, and host controls still need verification before audio reaches speakers.

Production Claims, Release State, and Upgrade Cost

The repository is not archived, and its last push was on 2026-10-17. The recent release history includes v1.1.6-beta2 on 2026-08-24, v1.1.6-beta3 on 2026-09-12, and v1.1.6-beta4 on 2026-09-28. Those dates show recent repository work, while the beta label means the newest listed firmware release should not be treated as a stable release based on this description alone.

The README labels both RP2040 and RP2350 as production and says they are fully tested and production-ready. It also identifies several firmware-specific details: RP2040 runs at 307.2 MHz with a slight voltage increase, and both platforms use a 1.15 V core voltage. Since no test procedure, board compatibility list, or independent validation is presented, adopters should match their exact board and power arrangement before relying on those claims.

Upgrade cost includes more than copying a UF2 file. Firmware updates depend on the host application's vendor command, and presets or DSP state may need transfer before or after an update. The documented protocol includes status and data structures, but the available description does not establish version negotiation, migration guarantees, or rollback behavior. Existing board designs also need pin-map and signal-level checks when moving between board types.

DSPi is licensed under GPL-3.0. That matters for anyone distributing modified firmware or incorporating its code into another product, because the license imposes source and distribution obligations. This is not legal advice, and organizations handling redistribution should review the license text against their intended use.

Where DSPi Differs from Host Software and Dedicated Processors

A conventional host audio application performs equalization, routing, or delay in software on the playback machine. DSPi moves those operations behind a USB audio endpoint, so the selected processing travels with the device rather than remaining tied to one particular host application. That is useful when several computers need the same output configuration, or when the audio chain must continue independently of software-based DSP.

A typical DAC or DSP board may offer a fixed filter or crossover menu exposed through front-panel controls or a vendor interface. DSPi instead documents a USB control protocol, bulk parameter transfer, named presets, runtime pin reassignment, and telemetry. This creates more configuration depth, but it also makes the quality and completeness of the host-side control experience important.

DSPi is therefore a middle path between playback software and a narrowly featured hardware processor. It is less convenient when the goal is simply to buy a finished USB DAC and select a basic tone control. It is more demanding than host software because external wiring, firmware deployment, and control-protocol integration are part of the project.

The decisive constraint is documentation depth. The README describes many DSP and routing capabilities, but the available content does not provide the full build commands, vendor protocol payload details, host application workflow, or rollback procedure. Those omissions matter more than the feature count when deciding whether the project is ready for a particular deployment.

Editorial conclusion

DSPi suits makers building a dedicated digital processor around a Pico, Pico 2, or another compatible RP2040 board, especially when room correction, crossovers, time alignment, and configurable digital outputs matter. It is a poor fit for users who need a ready-made host application, a documented rollback path, or a conventional audio-driver workflow without additional engineering. Before adoption, verify the hardware schematic and pin assignment, confirm that the missing flashing and host-control details are available for the intended board, and test the exact input and output topology required by the audio system. The documented result remains a purpose-built firmware project rather than a complete, self-guided installation package.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. WeebLabs/DSPi on GitHub