• 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

It really shows how sad the DSP market is
I agree - and the most amazing things is that thanks to Troy's generosity it's all open source! We've already seen one person modifying the software to meet their needs, so I'm sure if Weeb_Labs ever decide to step back from development and maintenance, the project will still live on in other forks.
 
H
It really shows how sad the DSP market is. There are so many units out there but they all seem to have pretty annoying drawbacks be it cost or garbage UI or just crappy feature set. I mean the Delay settings alone on this DSPi just embarass most other units. Something like a Dayton DSP408 is basically e-waste in comaprison.

I just ordered a few pico's to have around for this project. Replacing my 'Motu into a Motu' interface based DSP filters.
I agree, I bought a an AVR years ago as preamp just for bass management, 20kg lump for a sub out.
 
Thank you for the kind words, everybody. :)

I suspect that being a user of existing DSP products and having some experience of what most users want from them helps to steer things in the right direction!

The PCM5102A boards have arrived, so this should greatly simplify I2S testing. These are the direct result of contributions to the project.

IMG_0208.jpeg
 
how easy it would be for you to embed volume data in the user bits in the SPDIF signal?
Just realised that a) It's pretty simple and b) unless you like single-speaker mono the imaging would probably be a bit wobbly due to clock jitter, processing time and PLL wandering. I think? :oops:

If you have two Pico's receiving the same SPDIF signal, what would the maximum relative drift be (is it jitter?) between the I2S output of each Pico? Can someone with a bigger brain do the math? There are a lot of variables and I have no idea what the audible threshold of "wobbly imagness" is agreed to be.... :eek:
 
Just realised that a) It's pretty simple and b) unless you like single-speaker mono the imaging would probably be a bit wobbly due to clock jitter, processing time and PLL wandering. I think? :oops:

If you have two Pico's receiving the same SPDIF signal, what would the maximum relative drift be (is it jitter?) between the I2S output of each Pico? Can someone with a bigger brain do the math? There are a lot of variables and I have no idea what the audible threshold of "wobbly imagness" is agreed to be.... :eek:
This really depends upon a few different variables. I believe the best case scenario here would be an ESP32-C5 operating as the USB-I2S bridge and master, feeding your desired number of Picos as slaves. The Pico's processing is deterministic, so it would simply take I2S input from the ESP and output data on its clock edges. This should result in phase locked output across multiple Picos.
 
This really depends upon a few different variables. I believe the best case scenario here would be an ESP32-C5 operating as the USB-I2S bridge and master, feeding your desired number of Picos as slaves. The Pico's processing is deterministic, so it would simply take I2S input from the ESP and output data on its clock edges. This should result in phase locked output across multiple Picos.
It was specifically with relation to embedding the volume level into the user bits of SPDIF and sending one feed to each one of a pair of active speakers. So one DSPi/DSP32 transmitting two SPDIF signals with a DSPi on the end of each feed. Basically so you can run one cable per speaker, plus local mains, and have volume control over both speakers without losing bit-depth for the downstream DSPi filters. I know, it's a bit niche!
 
phase locked output across multiple Picos
I need this now!

Rather than adding a separate controller from another ecosystem, how about just putting it into the software of a Raspberry Pi 5 / CM5 unit?

So that it does not need to also be the player/renderer, (but could be).

Require use of a self-clocking physical transport that inherently embeds the phase / timing in the music signal bitstream.

I believe AES3 with BMC is supposed to do this better than S/PDIF.

Or DANTE for complex setups / very long distances?

These host / transport requirements would not apply to usage of a single DSPi, nor for those willing to "roll the dice" on latency / timing drift

just those requiring phase-accurate certainty in their multi-unit scenarios.

...

Of course if other kinds of coordination is needed between DSPi units

like a "master settings" UI

then carry both that signaling and the "master clock" data over the same transport

e.g. AES10 "user bits" as with how RME, does MIDI-over-MADI?
 
What an amazing project is this!

Question; would it be possible to add RC5 remote control, at least for the subwoofer output? I know the problem is that RC5 is not really standardized so it should be programmable which buttons on the RC you use. Or is this to far out of scope for the project?
I'd like to use it for my old (1992 or so!) Philips digital speakers DSS930, adding a subwoofer.

Me setting up a demo last Saturday April 11 in 's-Hertogenbosch, the Netherlands, where I used external processors to set up a proof of concept for it. With SPDIF in I can replace most of it by DSPi :) .
 
What an amazing project is this!

Question; would it be possible to add RC5 remote control, at least for the subwoofer output? I know the problem is that RC5 is not really standardized so it should be programmable which buttons on the RC you use. Or is this to far out of scope for the project?
I'd like to use it for my old (1992 or so!) Philips digital speakers DSS930, adding a subwoofer.

Me setting up a demo last Saturday April 11 in 's-Hertogenbosch, the Netherlands, where I used external processors to set up a proof of concept for it. With SPDIF in I can replace most of it by DSPi :) .
IR remote control is on the roadmap, along with many other external control types. It will be possible to learn any remote control code and assign it to any parameter.
 
Great! I will keep an eye on the developments.

B.t.w., the ADAT to SPDIF and the other way around I read some pages ago is also somehing that's on my wishlist for a long time.
 
A Great project, just wanted to give feedback ,I have it running with I2S Output on (the default) GPIO6 with a pcm5122 from adafruit, no problems, see screenshot.
 

Attachments

  • IMG_3300.jpg
    IMG_3300.jpg
    327.7 KB · Views: 134
A Great project, just wanted to give feedback ,I have it running with I2S Output on (the default) GPIO6 with a pcm5122 from adafruit, no problems, see screenshot.
I ordered 3 of them a few days ago due Monday.... amusingly I noticed checking my order they were now out of stock. Maybe all of us DSPi users bought them out.
 
A little update for those not following along in the Discord. This evening has been spent migrating the USB stack back to TinyUSB, as the existing pico-extras usb_device library does not have support for interrupt endpoints and it is essential that we have one of these for external control notifications.

The migration is now complete and the new interrupt endpoint is working properly. My targets for this weekend are to bring v1.1.3 out of beta and push the first beta for v1.1.4 with SPDIF input. :)
 
I upgraded to Windows DSPi Console v1.1.3-hotfix today. Looks good. Thanks for the continued hard work on this project.

A couple observations so far:

The Update Firmware function did not work for me, the USB drive did not appear in Explorer.

The Stats for Nerbs window does not populate any values for the the various listed attributes.

When I stream from Tidal, 24/96 tracks will not play. If I change the resolution to 16/44.1, they play. Have I missed posts about this?

Thanks
 
I upgraded to Windows DSPi Console v1.1.3-hotfix today. Looks good. Thanks for the continued hard work on this project.

A couple observations so far:

The Update Firmware function did not work for me, the USB drive did not appear in Explorer.

The Stats for Nerbs window does not populate any values for the the various listed attributes.

When I stream from Tidal, 24/96 tracks will not play. If I change the resolution to 16/44.1, they play. Have I missed posts about this?

Thanks
Could you confirm that you are running the latest v1.1.3-beta4 firmware?
 
This really depends upon a few different variables. I believe the best case scenario here would be an ESP32-C5 operating as the USB-I2S bridge and master, feeding your desired number of Picos as slaves. The Pico's processing is deterministic, so it would simply take I2S input from the ESP and output data on its clock edges. This should result in phase locked output across multiple Picos.
Could this ESP32-C5 handle 16 audio channels in and 16 out simultaneously? This is what I need to grab my AVRs I2S data and pipe it to CDSP.
 
Could this ESP32-C5 handle 16 audio channels in and 16 out simultaneously? This is what I need to grab my AVRs I2S data and pipe it to CDSP.
on paper yes, but with limitations, probably severe, on bit depth and frequency. The documentation is not very clear (to me) and i have not seen anyone reporting sucess with such channel count. @jmf11 has been playing with the P4, maybe he has experimented with how far it can go.
 
Back
Top Bottom