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

[john61ct]

Personally, TV is just another input, certainly not central.

Something analogous to ye ol' preamp to A. switch sources and B. (maybe separate device) allow for ad-hoc user control of volume level.

I'm curious how the volume control would work since each amp would have it's own knob for volume.

That's just for gain-matching, matching relative levels between channels.

Same with handling crossovers and bass management, set and forget.

I require my overall ad-hoc volume control to include automatic loudness contouring

and DSPi does feature that

but I dunno if/how multiple DSPi units could coordinate that

 

[frela412]

Personally, TV is just another input, certainly not central.

For me everything goes via my receiver basically. Which is nice because I don't have to think about much.

That's just for gain-matching, matching relative levels between channels.

I guess that makes sense, how high do people turn the individual amp? One on max and the rest just low enough to level it? Or the highest around 50%? If you keep them all lowish you're limiting how high you can play in general.

 

[markb]

@Weeb Labs Thank you for this amazing project -- it's been a lot of fun to play with the last few days, and it will be very useful for a number of use cases.

Except... it's been crashing for me. A lot. During regular playback (disappearing for a few seconds, coming back with any non-persistent settings gone), but especially also when making (configuration changes).

Because I saw few other reports here, I first suspected my hardware setup. Was it my Waveshare Pico Hat? My breadboarded coax SPDIF-out? But eventually I was seeing the same issues with just the bare board connected over USB, and nothing else attached.

I ended up running an extensive debugging session with Claude, having it implement an uptime timer and (watchdog) reset reason telemetry. Then had it instrument much of the code to try to pinpoint the cause of the memory corruption observed, and bisected much of the 1.1.6 branch I was running. But 1.1.5 suffered from it too. I should have just gone with my initial hunch: a voltage/overclocking issue. I didn't buy the stock Raspberry Pi Pico 2, but the Waveshare RP2350-Plus instead. Really only because it has a USB-C connector and I really avoid buying more Micro-USB if I can.

Rebuilding with either a much lower clock speed, or a slightly elevated core voltage of 1.20V seems to have fixed the issue.

I'm not sure if it warrants upping the voltage for everyone, because it's clearly not a very widespread issue. It might even be wonky power decoupling on just my board. But it can be very annoying to fix for those affected.

I already filed an issue on Github -- I'm mainly reporting here in case others are perhaps seeing similar symptoms.

 

[Weeb Labs]

@Weeb Labs Thank you for this amazing project -- it's been a lot of fun to play with the last few days, and it will be very useful for a number of use cases.

Except... it's been crashing for me. A lot. During regular playback (disappearing for a few seconds, coming back with any non-persistent settings gone), but especially also when making (configuration changes).

Because I saw few other reports here, I first suspected my hardware setup. Was it my Waveshare Pico Hat? My breadboarded coax SPDIF-out? But eventually I was seeing the same issues with just the bare board connected over USB, and nothing else attached.

I ended up running an extensive debugging session with Claude, having it implement an uptime timer and (watchdog) reset reason telemetry. Then had it instrument much of the code to try to pinpoint the cause of the memory corruption observed, and bisected much of the 1.1.6 branch I was running. But 1.1.5 suffered from it too. I should have just gone with my initial hunch: a voltage/overclocking issue. I didn't buy the stock Raspberry Pi Pico 2, but the Waveshare RP2350-Plus instead. Really only because it has a USB-C connector and I really avoid buying more Micro-USB if I can.

Rebuilding with either a much lower clock speed, or a slightly elevated core voltage of 1.20V seems to have fixed the issue.

I'm not sure if it warrants upping the voltage for everyone, because it's clearly not a very widespread issue. It might even be wonky power decoupling on just my board. But it can be very annoying to fix for those affected.

I already filed an issue on Github -- I'm mainly reporting here in case others are perhaps seeing similar symptoms.

Hello and thank you for the kind words! It certainly sounds as though your board might have been a victim of the silicon lottery. If memory serves, you are actually the very first user to receive a board that is unstable at the default 307.2MHz/1.15V. I'm glad that you were able to resolve it by raising the voltage.

In the very near future, I will be releasing a beta which includes support for voltage and frequency selelction, up to 480MHz and 1.5V, with automated benchmarking for selection.

 

[Rafsky]

Hello and thank you for the kind words! It certainly sounds as though your board might have been a victim of the silicon lottery. If memory serves, you are actually the very first user to receive a board that is unstable at the default 307.2MHz/1.15V. I'm glad that you were able to resolve it by raising the voltage.

In the very near future, I will be releasing a beta which includes support for voltage and frequency selelction, up to 480MHz and 1.5V, with automated benchmarking for selection.

Adding a small heatsink might ensure greater stability and lower operating voltage; I tested the DSP with 10 active PEQs and a 48dB/octave crossover per channel and reached about 40% CPU usage—I wonder what else that extra computing power could be used for. Congratulations on the efficiency achieved!

 

[Weeb Labs]

Adding a small heatsink might ensure greater stability and lower operating voltage; I tested the DSP with 10 active PEQs and a 48dB/octave crossover per channel and reached about 40% CPU usage—I wonder what else that extra computing power could be used for. Congratulations on the efficiency achieved!

40% sounds quite high! How many channels do you have and at which sample rate? I have measured about 13% utilization (core 0) with 10 bands on two channels at 48KHz.

 

[Kessito]

Hey all!

First of all thanks @Weeb Labs for this amazing project. I'm currently experimenting with different I/O configurations and I stumbled upon a weird issue. I hope someone will help me debug this.

The Problem
I'm getting tiny audio dropouts on left or right channel (not at the same time) when DSPi is configured as SPDIF in and SPDIF out.

Setup
I'm using my audio interface (RME UCX II) to feed AES/EBU signal through this breakout board into DSPi running on RP2350 Tiny. SPDIF Input set to default input pin GPIO5.
On the output side I'm using default SPDIF output pin GPIO6 and connecting it to the same breakout board. AES/EBU output feeds my Genelec speakers.

RME -> AES/EBU In -> DSPi GPIO5 -> [*] -> DSPi GPIO6 -> AES/EBU Out -> Genelec 8340

I'm running the latest stable release of DSPi firmware - v1.1.5, sample rate set to 48kHz

Testing done
- First I've tested SPDIF transmitter on DSPi side and I'm dropout free audio
- Set DSPi input to USB
- Set DSPi output to SPDIF
- All the connections as per input

- Then I've tested SPDIF receiver on DSPi side
- Set DSPi input to SPDIF
- Set DSPi output to SPDIF
- Enable bulk output, add toslink connector on Pin 4
- feed ADAT back to RME, play back on headphones
- in this case I'm getting glitch free audio as well which means that the receiver works well too

- Lastly I've tested both SPDIF rx and tx at the same time using RME only to rule out the speakers are the problem
- set DSPi input as SPDIF
- set DSPi output as SPDIF
- digital input from RME
- digital output back to RME (aes/ebu)
- play back aes/ebu return signal on the headphones
- I'm getting much fewer glitches but they happen occasionally. RME has amazing clock recovery while genelecs use off-the-shelf akm digital receiver IC so that could explain it.


Any pointers on where to start looking? Stats in the DSPi console don't give me much. I'm comforable building the code if that's what it takes to figure this out.

View attachment 557517

Does this board also have a src chip? or is it only rs485 transceiver?

 

[66o_]

Does this board also have a src chip? or is it only rs485 transceiver?

No, the input board has a transformer followed by a transceiver. Here's the schematic. I've done more testing and I found out that the glitches only happen during a couple of minutes after reboot. Then things seem to get stable.

 

[gadget-man]

Be careful with firmware v1.1.6-beta3! The upgrade deleted all my presets. Did I miss something?

 

[Sonic-Wall]

No, same here.
In addition, the input selection in the main window disappeared.
Renaming of the preset name also doesn‘t work.
Do we need also the DSPi console 1.1.6-beta3?

 

[Weeb Labs]

I will be posting the Beta 3 announcement later this evening, which will include an updated Console release and an in-place update to the firmware itself. For now, please pretend it doesn't exist.

 

[Sonic-Wall]

Hi Troy,
after some debugging I think there is an issue with the I2S clocks switching between master and slave modes.

My setup:
I use an input board with Coax and I2S inputs and an I2S output.
In addition I use an output board with an I2S input and multiple different outputs (Toslink, Coax, I2S).
DSPi sits in between both boards.
I have setup my system in a way that I can switch between the USB input of the DSPi and my input board by switching between two different DSPi presets.
For the USB input one config is using DSPi as the master routing the clocks to the output board.
To switch to the input board I have defined DSPi as slave receiving MCLK (Unified clock Pins) from my input board.
Hence the setup in this case looks like this:
DDC (I2S output) --> input board (I2S input) --> input board (I2S output) --> DSPi (I2S input) --> DSPi (I2S output) --> output board (I2S input) ... --> DAC

If I switch between the configs sometimes DSPi doesn't manage to output a correct signal. If I remove the power of my input board the USB input to I2S output works, even the I2S input of the DSPi should be inactive. Switching from USB to the input board always works. However it takes some time to synchronize.
Any idea how to fix this problem?

 

[Weeb Labs]

Hi Troy,
after some debugging I think there is an issue with the I2S clocks switching between master and slave modes.

My setup:
I use an input board with Coax and I2S inputs and an I2S output.
In addition I use an output board with an I2S input and multiple different outputs (Toslink, Coax, I2S).
DSPi sits in between both boards.
I have setup my system in a way that I can switch between the USB input of the DSPi and my input board by switching between two different DSPi presets.
For the USB input one config is using DSPi as the master routing the clocks to the output board.
To switch to the input board I have defined DSPi as slave receiving MCLK (Unified clock Pins) from my input board.
Hence the setup in this case looks like this:
DDC (I2S output) --> input board (I2S input) --> input board (I2S output) --> DSPi (I2S input) --> DSPi (I2S output) --> output board (I2S input) ... --> DAC

If I switch between the configs sometimes DSPi doesn't manage to output a correct signal. If I remove the power of my input board the USB input to I2S output works, even the I2S input of the DSPi should be inactive. Switching from USB to the input board always works. However it takes some time to synchronize.
Any idea how to fix this problem?

It sounds like you might be encountering clock collisions here. The I2S input board is a clock master and when DSPi is also configured as a master (USB->I2S), both DSPi and your input board are supplying clocks to the output board. This is why you hear sound in the USB->I2S configuration when disconnecting power from your I2S input board.

This is an electrical problem rather than a firmware one. Switching between master and slave modes without changing the wiring can't really work.

 

[Sonic-Wall]

Yes, you are probably right.
However, due to the DSPi architecture I‘m forced to use shared clock pins (BCK, LRCK) and in my case also MCLK.
Switching between master and slave mode could lead to an instability of the clock signals.
Maybe this is the reason why many input boards have separate I2S inputs and outputs.
Would it be possible to add an option for DSPi to have completely separate I2S inputs and outputs?

 

[Rafsky]

40% sounds quite high! How many channels do you have and at which sample rate? I have measured about 13% utilization (core 0) with 10 bands on two channels at 48KHz.

High? I thought it was super efficient :-D anyway, I’ve set the crossover and 10 PEQ bands on each of the 8 channels (48kHz).

 

[Weeb Labs]

High? I thought it was super efficient :-D anyway, I’ve set the crossover and 10 PEQ bands on each of the 8 channels (48kHz).

Ah, all eight channels. That’s more inline with expected performance.

 

[Weeb Labs]

This week's release had been a little bit delayed due to a hospital stay and subsequent recovery period but at last I am happy to announce the release of DSPi Firmware and Console for macOS v1.1.6 Beta 3.

Users of Console for macOS will only need to download the Console application and not the firmware itself, as will be explained shortly.

I had originally planned for this update to focus purely on quality of life enhancements but as usual, that's not quite what happened! Instead we have a whole host of handy new functions today.

Here is the non-exhausive list of changes:

• RP2350/2040: Hybrid FFT/RTA engine now enables multiple input or output channels to be analyzed and displayed either as bar or spectrum graphs. The engine consists of a 1024-point FFT and an efficient low frequency filter bank, which provide high resolution output across the full audio band at a CPU utilization cost of 1% per channel.
• RP2350/2040: Subharmonic Synthesizer has been added as a new effect module. This is an extremely accurate recreation of the classic dbx A120 with an additional band and the ability to target either percussion or sustained content. Handy for adding bass to deficient recordings where EQ doesn't help. A Solo function enables just the synthesized bass to be heard.
• RP2350/2040: Auxiliary Outputs for Control Surfaces now enables user-defined GPIO outputs; both toggled and dimmed. This can be used to control relays, lights, amplifiers, fans or other non-audio hardware either via buttons or a front panel display. Outputs have persistent names and can be added to the Displays dashboard.
• RP2350/2040: Every build now contains both a readable Git hash and beta number, making it easy for users and developers alike to know exactly what they are running and when it was built.
• RP2350/2040: Fixed bugs which sometimes resulted in blank displays on boot if bar controls were enabled and prevented the source selection from wrapping around when adjusted via button or rotary encoder.
• Console for macOS: New users will now be presented with an onboarding screen, which guides them through the process of installing DSPi on their Pico.
• Console for macOS: Each Console release now ships with the correct firmware version bundled and prompts to update the user's Pico automatically upon launch. The Firmware Update window has been redesigned acccordingly.
• Console for macOS: Support for FFT/RTA displays has been added. They can be shown either on the response graph or below it as a dedicated card with support for multiple channels in both instances. The card display is resizeable. A dedicated Spectrum Analyzer window is also available and tracks engine's current state.
• Console for macOS: The Filter Response graph now includes a pop-over menu with FFT/RTA settings and a second page exposing detailed graphing options which had previously been buried within the main settings window.
• Console for macOS: Numerous optimizations have been made in order for Console to make better use of available space when the window is made larger. Both the RTA card and dashboard filter lists will now grow horizontally to take advantage of wider window configurations.

The corresponding Console for Windows update will be arriving very soon. I am also working on iOS and Android applications which work in conjunction with the new DSPi Link protocol, so expect to see glimpses of those as development progresses.

The usual disclaimer: While great care has been taken to thoroughly test all functionality, some bugs may remain. Should you encounter a bug or unexpected behavior, please don't hesitate to make a report so that it can be squashed! You can do that either here, on GitHub or via the Discord server (many helpful people there).

Finally and as always, DSPi is a not-for-profit open source project funded entirely by donations and out of pocket. If you wish to support the project, you can do that via Ko-fi or Patreon.

 

[Brunello Candelaresi]

I have to commend the idea and the speed at which the project is developing; I encountered difficulties connecting the DAC (SMSL C200) via S/PDIF using the schematic found in the discussions, whereas the connection worked immediately when I used this old interface from an Asus computer. A second issue was getting the PCM5102 boards to work, until I found an image online showing the correct jumpers to set on the board.

I also successfully connected the DSPi ESP32 media player; the only problem encountered during firmware compilation was having to change the preset COM port from COM10 to COM6, as that was the port identified by my computer.

A truly interesting project that I have already recommended to my friends.

 

[TOMSON]

PCB DSPi + ESP32C3 XIAO Active 3-way crossover

 

[john61ct]

WOW, just wow.

Best wishes for speedy and FULL recovery!

To anyone - I've been using AudioControl Epicenter - analog only I believe? Feedback please...

And over time, please help me understand how (functionally) this new "Subharmonic Synthesizer" feature compares?