• Welcome to ASR. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

Introducing DSPi | A powerful, user friendly and open source DSP for less than a cup of coffee

I just want to say that this is cool as shit. Years ago I tried convincing a standard Raspberry Pi to simultaneously act as a standard USB audio soundcard and a on a different physical port as a USB host, to process incoming audio and send it to a real soundcard. Afaik the hardware theoretically supports this and the drivers exist, but I wasn't able to actually make it work.
So kind-of-a USB EQ injector? If I understand it correctly:
1. as is, the DSPi pico can act as a USB audio soundcard (USB device) and output digital audio through a SPDIF output. You can connect it to a DAC/AMP with SPDIF input to get equalised sound. This works nicely right now.
2. The standard pico USB port can’t work as an USB host, so feeding audio through a (not yet implemented) SPDIF input and connecting a USB audio soundcard is NOT supported (unless I’m wrong).
3. Theoretically, you can program two pico gpios as the D+/D- USB signals, using the pico PIO feature. The TinyUSB library that DSPi uses supports this (bit banging the GPIOs); in USB host mode as well. So “maybe” this could be used to support that scenario in the future, but I’m not aware of any OS project that has implemented this for USB audio. But using your words, the pico will not be easy to convince because of multiple potential issues (clock sync? ASRC? Enough PIOS / GPIO? Processing power?).
4. Because of 2., connecting together two picos through SPDIF (or I2S in the future) one acting as USB device and the other as host would not work. Maybe other MCUs support that.
 
Slightly off topic but would it be technically possible to have multiple I2S inputs like from those HDMI to I2S boards so we can mix multi channel audio? Might be too much to handle for the Pico but I imagine this would be a poor man’s audio processor for surround applications (bass management, channel routing/delays, etc).
This might be possible if the HDMI-I2S board provides a set of clocks, which it should. The idea would be for the Pico to operate as an I2S slave, with data being output on the rising edge of the external bit clock. The Pico would effectively just be responsible for processing the audio data, with all clocks being sourced directly from the master device.

It's quite a complex thing to implement but I will perform some experiments when I have the time. There is an existing I2S library which may have support for this.
 
At the moment, the master clock would be generated via the PIO divider. The amount of jitter depends upon a few factors. Minimizing it at the moment would entail using a system clock frequency that enables an integer PIO clock divider rather than a fractional one.

Another approach is to make use of I2S DACs with internal PLLs that do not require a master clock or an ASRC.

Ultimately, the custom DSPi board design will likely make use of an external clock source for the PIO, producing minimal output jitter for I2S and TDM8.
Thanks. So what clocks the PIO? I read the controller can be clocked from an on-chip ring oscillator or a crystal. Is there a crystal on the Pico? Does it use its own clock for the FIFO on the USB in?
 
Thanks. So what clocks the PIO? I read the controller can be clocked from an on-chip ring oscillator or a crystal. Is there a crystal on the Pico? Does it use its own clock for the FIFO on the USB in?
The Pico has an onboard 12MHz crystal reference, which its PLLs use to generate the system clock (288MHz in this case). The PIO is clocked through a divider which reduces this system clock to the 12.288MHz required by the SPDIF BMC.

One of the most egregious sources of output jitter results from the use of a fractional divider to arrive at the required PIO clock, so when preliminary I2S output is implemented, I will be switching to a system clock which enables the use of an integer divider. This will eliminate fractional jitter, leaving only the far less objectionable and random PLL phase noise.

The USB input uses the Pico's own clock and manages drift using the feedback endpoints.

In other news, clipping indicators, biquad efficiency improvements, metering for all 9 output channels and DSPi Console optmizations are on the way in the next commits and release. DSPi Console for macOS and Windows currently redraw the response chart continuously, so there are significant performance improvements to implement. :)
 
Last edited:
There are also cheap SRCs available for less than 7$ that can be used in slave mode to upsample the I2S input to 48k/96k/192k.
Of course there are also more expensive SRCs available that support PCM/DSD and up to 768k.
It would be great, if you could support I2S outputs, as it offers so many options to enhance the system, by just taking advantage of the many tiny boards that are available on Aliexpress :-)
 

Attachments

  • IMG_1213.jpeg
    IMG_1213.jpeg
    120.6 KB · Views: 105
  • IMG_1214.jpeg
    IMG_1214.jpeg
    99 KB · Views: 100
Last edited:
Flashed the precompiled dspi RP2040 uf2 and got the console running fine, but I’m seeing only the L channel actually responding to changes. ML/OL affect both speakers, but R(MR/0R) control doesn’t seem to reflect anything independently.



I’m using a Sounce 192KHz SPDIF Optical to Analog L/R RCA DAC along with a Raspberry Pi Pico 2 W. I wired everything exactly as per the provided schematic ,the SPDIF coax output feeds into the DAC, and the DAC’s L/R RCA outputs go directly to the amplifier



Is the current uf2 build running mono internally, or am I missing something in the firmware/console version match? Any help would be appreciated :)
 
Last edited:
Flashed the precompiled dspi RP2040 uf2 and got the console running fine, but I’m seeing only the L channel actually responding to changes. ML/OL affect both speakers, but R(MR/0R) control doesn’t seem to reflect anything independently.



I’m using a Sounce 192KHz SPDIF Optical to Analog L/R RCA DAC along with a Raspberry Pi Pico 2 W. I wired everything exactly as per the provided schematic ,the SPDIF coax output feeds into the DAC, and the DAC’s L/R RCA outputs go directly to the amplifier



Is the current uf2 build running mono internally, or am I missing something in the firmware/console version match? Any help would be appreciated :)
If you have a Pico 2 (RP2350), then you will need to flash the RP2350 UF2. That should solve your problem. :)
 
Is the CLI still waiting some love, or have I just missed it? v1.1.0 on Pico (RP2040) appears as an audio device in linux, complete with mute and volume control in alsamixer, but I don't think there's anything I can use to configure it or check what the defaults are. I haven't tried the Windows version with wine yet - typically it won't work for anything connecting to a driver, but with libusb there might be some hope.
 
Is the CLI still waiting some love, or have I just missed it? v1.1.0 on Pico (RP2040) appears as an audio device in linux, complete with mute and volume control in alsamixer, but I don't think there's anything I can use to configure it or check what the defaults are. I haven't tried the Windows version with wine yet - typically it won't work for anything connecting to a driver, but with libusb there might be some hope.
I'm afraid I haven't had very much time to work on the CLI version just yet but I will do my best to push the first release this evening.

Greetings from Ireland!

Thank you for this project. Will definitely be interested to dive into, when time allows.
I am also in Ireland! I look forward to hearing your thoughts on the project.
 
My intended signal chain is:

PC → DSPi via TOSLINK → DX5 II DAC (speaker PEQ applied) → Cambridge Audio amplifier → Wharfedale Diamond 12.1 loudspeakers
PC → DSPi RCA subwoofer output → BK Electronics XXLS400-FF subwoofer

The missing link would be that my current TV TOSLINK into the DX5 II wont have bass management. The Source has to be a PC from my understanding.
Yeah, hifi is separate to computer. PC or laptop to do some assessment and programming, then out of the chain. It's not hifi, it's a totally different tool. I have at least three current systemps for audio use, all pretty good quality. One setup can then be tweaked and repleicated. Cost is trivial.
 
Up and running now, and as other folk have said, it's all rather lovely and I'm slightly in awe. One small issue - 16 bit input only, if I have understood correctly. Does this mean that for at least some SW players 24 bit material will be truncated without dither?
 
Up and running now, and as other folk have said, it's all rather lovely and I'm slightly in awe. One small issue - 16 bit input only, if I have understood correctly. Does this mean that for at least some SW players 24 bit material will be truncated without dither?
I'm glad everything is working well. The host is presented with a USB endpoint that specifies 16-bit as the only supported format so it will be handling conversion and dither.
 
I'm afraid I haven't had very much time to work on the CLI version just yet but I will do my best to push the first release this evening.
Thanks. I seem to be the only one asking about it anyway, and may be able to fill in some of the missing bits.
 
I was going to buy a Minidsp Flex HTx and I'm going to wait to see how this project develops. I am after a dsp with multiple analogue inputs with delay and peq, nothing fancy. I am expecting multiple Picos with DSPi will be exactly what I am looking for.
 
Im trying to get PDM sub output. There's no signal showing on the console PDM SUB output bar
Do I need to turn on something?
 
Im trying to get PDM sub output. There's no signal showing on the console PDM SUB output bar
Do I need to turn on something?
If you are running the most recent v1.1.0, you will need to open the Matrix Mixer via Tools on the menu bar, enable the PDM output and route both channels to it. Ensure both route gains are set to -6dB.
1771265690581.png

This is an RP2040. For the RP2350, you will have more SPDIF channels but the steps are the same.

EDIT: If you are running Windows, then I would recommend using firmware v1.0.7 for the moment. The DSPi Console for Windows has not yet been updated with the new architecture.
 
Last edited:
Back
Top Bottom