• 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

@Weeb Labs

Great project. It would be really nice to have a typical CHANGELOG on the github repo. it really useful especially when you make some breaking changes. Could help save a lot of time.

If some day you decide to put it into case with outputs spdif/i2s/.. will definitely buy it.

P.S.
how can I support you ?
 
So basically, the DSPi sits between the source(s) (computer, TV, CD player, gaming console, etc.) and the DAC or multiple DACs (depending on the intended use).

Currently, it can be used for room, speaker, or headphone correction via parametric EQ
and/or
to perform a crossover between a subwoofer and a pair of speakers, or to create multiple crossovers between the drivers of DIY active speakers.

In short, it does the work of a traditional DSP for a fraction of the price.

But other uses are either already planned or potentially feasible.
Thanks, I still have unanswered if it needs to have the computer or not. I am looking for something like the miniDSP which can be programmed with curves then disconnected from the host device and just sit there, filtering/tweaking, and receiving, processing, and sending a signal on its way.
Assuming that's the goal for all of these device types.

I feel churlish asking three times but the lengthy discussion never really approached the blindingly obvious, to my eyes anyway.
You buy some cheap stuff(unknown) program them/it, use it without a computer, that's what I understand a hifi DSP to be.
 
Thanks, I still have unanswered if it needs to have the computer or not. I am looking for something like the miniDSP which can be programmed with curves then disconnected from the host device and just sit there, filtering/tweaking, and receiving, processing, and sending a signal on its way.
Assuming that's the goal for all of these device types.

I feel churlish asking three times but the lengthy discussion never really approached the blindingly obvious, to my eyes anyway.
You buy some cheap stuff(unknown) program them/it, use it without a computer, that's what I understand a hifi DSP to be.
You only need a computer to upload the firmware to the Pico and then configure the filters, I/O etc. Then you can connect it to a device that can do audio over USB or (when it's available) SPDIF.
 
Here are some measurements of the new hybrid filter implementation, along with the values in use for reference. It is very well behaved. :)

1772751857609.png

1772751885134.png


And finally, a comparison between the responses of the previous traditional RBJ biquads and the new architecture.

1772752839606.png

Absolutely identical. You can ignore the tiny ripples; those are simply my interface misbehaving.
 
Last edited:
Hi. I just printed a custom 3d case. It came out too small, but with a cutter, everything fitted in somehow.

20260304_133308.jpg
20260304_131433.jpg

20260304_133234.jpg


I'm still working on a firmware for a ESP32-C6-LCD-1.47 display console / DSPi companion, with very limited features (show meters, preset toggle). Instead of using WinUSB, it communicates with the pico using UART (or I2C). The one shown in the pictures is self developed, but today I did some tests with ESPHome, and I'm impressed, it's basically all there with almost no coding (LVGL UI design, rotary encoder, OTA firmware install, logs, I2C & I2S support, UART protocols).
 
Is this measurement from digital signal or in analog domain?
Might be interesting to see the behaviour of low/high pass in LF, but I am sure it is good enough.
 
Is this measurement from digital signal or in analog domain?
Might be interesting to see the behaviour of low/high pass in LF, but I am sure it I good enough.
This is a digital measurement, captured directly from the SPDIF output. Low pass and high pass exhibit exactly the same noise floor characteristics, with noise floor just below -122dBFS.
 
Last edited:
Might be interesting to see the behaviour of low/high pass in LF, but I am sure it is good enough.
I feel like the hardest filter test is just to apply:

Frequency = 25 hz
Q = 10
Gain = -15 dB

That makes a very narrow deep cut in the bass that makes a very long ringing filter which finds rounding precision problems.
 
That makes a very narrow deep cut in the bass that makes a very long ringing filter which finds rounding precision problems.
Sure, if it aces the worst case then we don't have to look further, but if not, it might still be perfectly fine for most typical cases.
In comparison to the results for other DSPs there seems to be a lot of rounding noise (in particular in HF, where it counts) already, or is there a fundamental difference in the measurements that I do not see?

Next is another SHARC based platform the 2x4HD which shows similar issues to the miniSHARC.
[...]

Low - 2x4HD
2x4HD Multi Low -10 dB.png


2x4HD Low 100 Hz -1 dB.png


Base: Input RMS -1.03 dBFS, THD: -145.6 dB based on 49 harmonics [20..22000 Hz], N: -129.5 dB [20..22000 Hz], THD+N: -129.4 dB [20..22000 Hz]
Low: Input RMS -5.38 dBFS, THD: -143.7 dB based on 49 harmonics [20..22000 Hz], N: -102.9 dB [20..22000 Hz], THD+N: -102.9 dB [20..22000 Hz]

High - 2x4HD
2x4HD Multi High -10 dB.png


2x4HD High 1 kHz -1 dB.png


Base: Input RMS -1.01 dBFS, THD: -145.8 dB based on 21 harmonics [20..22000 Hz], N: -129.6 dB [20..22000 Hz], THD+N: -129.5 dB [20..22000 Hz]
High: Input RMS -10.75 dBFS, THD: -144.1 dB based on 21 harmonics [20..22000 Hz], N: -121.8 dB [20..22000 Hz], THD+N: -121.8 dB [20..22000 Hz]
 
Sure, if it aces the worst case then we don't have to look further, but if not, it might still be perfectly fine for most typical cases.
In comparison to the results for other DSPs there seems to be a lot of rounding noise (in particular in HF, where it counts) already, or is there a fundamental difference in the measurements that I do not see?
It looks like different bucket width.
 
Sure, if it aces the worst case then we don't have to look further, but if not, it might still be perfectly fine for most typical cases.
In comparison to the results for other DSPs there seems to be a lot of rounding noise (in particular in HF, where it counts) already, or is there a fundamental difference in the measurements that I do not see?

The baseline noise floor in these measurements is about -144dBFS, which is the expected value for a 24-bit signal. The baseline noise floor in my measurements is about -122dBFS with a 64k FFT. It is important to bear in mind that the MiniDSP implements full 64-bit accumulation handling for the internal pipeline.

It is certainly possible to make use of this approach in DSPi but it would be very expensive on an RP2350 without delivering any audible benefit in comparison with the current noise floor.

I feel like the hardest filter test is just to apply:

Frequency = 25 hz
Q = 10
Gain = -15 dB

That makes a very narrow deep cut in the bass that makes a very long ringing filter which finds rounding precision problems.

Here is that filter. The SVFs don't exhibit the low frequency precision issues inherent to RBJ biquads.
1772761307672.png


1772761421923.png
 
The baseline noise floor in my measurements is about -122dBFS.
Thanks. While that does not look overly superb for a digital signal it is plenty "good enough", as this "noise" is correlated to the signal and will decrease with small signal level.
And the 25Hz filter result shows that it is robust, because of the hybrid approach.
 
Yes, for a purely digital signal it looks not so great but is probably adequate. How much is really due to rounding noise in the internal pipeline and how much is due to the ASRC which must be in the signal chain if you use SPDIF in?

You wrote above that the ASRC is at -120 dB noise level which is just what we are seeing in these pictures, so I suspect it might look much better with USB in? After your post with the -120 dB ASRC, I looked at the AD1896 data sheet. That is the newest and best standalone ASCR from AD (data sheet is from 2003, device design is probably older). It is specified at -117 dB THD+N under worst case conditions, apparently when upsampling 4x. However, all the spectra in the data sheet look much cleaner than that, with grass or spuriae typcially at -140 dB and occasionally at -130 dB. If the same applies to your implementation, the typical ASCR noise should also sit at -140 dB and would not be the culprit in the filter measurements above.

Which takes me to the word length. From post #1:
32-bit float audio pipeline with 64-bit internal for the RP2350 (32-bit fixed point for the RP2040)

So doesn't the 2050 have the internal word length anyway? Why would it be expensive to go to 64 bit on the 2050? I understand why on the 2040.

If the culprit happens to be the ASCR and not the filter pipeline, would extending the word length only on the ASCR be possible and save cycles?
 
Yes, for a purely digital signal it looks not so great but is probably adequate. How much is really due to rounding noise in the internal pipeline and how much is due to the ASRC which must be in the signal chain if you use SPDIF in?

You wrote above that the ASRC is at -120 dB noise level which is just what we are seeing in these pictures, so I suspect it might look much better with USB in? After your post with the -120 dB ASRC, I looked at the AD1896 data sheet. That is the newest and best standalone ASCR from AD (data sheet is from 2003, device design is probably older). It is specified at -117 dB THD+N under worst case conditions, apparently when upsampling 4x. However, all the spectra in the data sheet look much cleaner than that, with grass or spuriae typcially at -140 dB and occasionally at -130 dB. If the same applies to your implementation, the typical ASCR noise should also sit at -140 dB and would not be the culprit in the filter measurements above.

Which takes me to the word length. From post #1:
32-bit float audio pipeline with 64-bit internal for the RP2350 (32-bit fixed point for the RP2040)

So doesn't the 2050 have the internal word length anyway? Why would it be expensive to go to 64 bit on the 2050? I understand why on the 2040.

If the culprit happens to be the ASCR and not the filter pipeline, would extending the word length only on the ASCR be possible and save cycles?
There is no ASRC active in the posted measurements. Those were captured using the USB input.

The original implementation did make use of 64-bit accumulators but some of the coefficient computation was handled in single precision. Performance would have been quite similar to the above, while consuming 30% more DSP instructions.

A fully double precision pipeline was possible but would have limited the total number of filters to about 50 rather than the current 130. This is significant when taking into consideration the number of output channels now available.

Rather than chasing ever higher numbers at the expense of usefulness, my objective is audibly perfect output under all probable real world conditions. :)
 
Thanks for the clarification. So by how much would it degrade if the ASRC were used?

I understand your approach, especially now that I have heard about your mixing use case. But in my experience, components in the signal chain with - 80 dB harmonics, noise or spuriae result in a lackluster sound when used with good source material and good loudspekers or headphones. Not that is a far cry from -120 dB, but with the possibility of ASCR and digital attenuation further degrading the margin, it is not what I would want to have in my main chain.

How much effort would it be to make the pipeline length user selectable? Can this be compensated by dropping 2040 support? The price difference is about €2, so everyone who doesn't happen to have a Zero 1 in the drawer should be getting a Zero 2 anyway.

The other question is, who needs 130 filters? Even elaborate four way designs like the Linkwitz LX521.4 use fewer than 50 filters by my count.

 
Last edited:
I suspect there may actually be a problem with SPDIF receiver of the rather old interface being used to capture these measurements, so the above may not be fully representative of the actual output performance.

1772791034557.png

This is closer but still incorrect below 100Hz. Actual output noise floor is likely closer to the -144dBFS of the MiniDSP measurements posted earlier. One of the developers contributing to the project had previously captured measurements using a rather fancier interface which more closely aligns with the above.

I am currently attempting to source a more suitable interface in order to confirm these suspicions.

EDIT: This is indeed an audio interface limitation. Actual noise floor is much lower than previous measurements indicate. I will be purchasing a more suitable interface shortly.
 
Last edited:
I suspect there may actually be a problem with SPDIF receiver of the rather old interface being used to capture these measurements, so the above may not be fully representative of the actual output performance.

View attachment 515523
This is closer but still incorrect below 100Hz. Actual output noise floor is likely closer to the -144dBFS of the MiniDSP measurements posted earlier. One of the developers contributing to the project had previously captured measurements using a rather fancier interface which more closely aligns with the above.

I am currently attempting to source a more suitable interface in order to confirm these suspicions.

EDIT: This is indeed an audio interface limitation. Actual noise floor is much lower than previous measurements indicate. I will be purchasing a more suitable interface shortly.
Wow. This is about as good as it gets and certainly more than adequate! Did you obtain this with your existing interface, and if so, what did you change?
 
FYI, the rising noisefloor in your loopback measurments indicate Jitter.
If you do a real loopback (input to output spdif) , and make sure the device is locked to spdif input it should vanish.

If you want to spare yourself the headaches of not 100% reliable audio hardware for your measurments, do yourself a favor and buy a RME interface, not the cheapest option, but the only one that has proven rocksolid drivers for over 30 years.

I am sure we could all chip in with a small donation for your great efforts :)
 
Boy, my breadboarding skills are approaching minimally acceptable. I got some RCA jacks and managed to wire up a coax connection after figuring out which holes the resistor leads went into. This is almost as great as making chlorine in high school chemistry. I didn't get a nosebleed from wiring up the coax out, though.
 
FYI, the rising noisefloor in your loopback measurments indicate Jitter.
If you do a real loopback (input to output spdif) , and make sure the device is locked to spdif input it should vanish.

If you want to spare yourself the headaches of not 100% reliable audio hardware for your measurments, do yourself a favor and buy a RME interface, not the cheapest option, but the only one that has proven rocksolid drivers for over 30 years.

I am sure we could all chip in with a small donation for your great efforts :)
You are absolutely correct. I am going to implement a simple loopback via the DSPi's own USB endpoints, which will enable me to accurately measure the pipeline performance without depending upon an audio interface. I will be using conditional compilation and leaving the loopback in place, allowing users to independently validate the performance of their configuration if desired.

I've been meaning to purchase an RME ADI‑2 Pro FS R interface for quite some time. Ideal for measurements but by no means an impulse buy!
 
Last edited:
Back
Top Bottom