• 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

That is a very peculiar issue and the first time I have heard of this one. Could you possibly share some photos or diagrams of your hardware setup?

A little PSA for users of v1.1.2a who encounter fluctuating core 0 utilization and occasional underruns during playback: I have identified a bug that has been present since v1.0.9 wherein buffer prefill leads to intermittent USB IRQ blocking. This will be patched in the next release and will completely eliminate this (admittedly uncommon) issue. It will also completely eliminate underruns when initiating playback.

I have been attempting to trace this particular bug for the last couple of weeks. It must be squashed before I2S output and SPDIF input can be implemented, so I'm very glad that I found it. :)
Yes, sure. I have attached images of my hardware setup. I built the circuit provided in the GitHub repository, used an RCA connector, and connected it to a DAC. Then, I connected it to the amplifier and speaker.


26649.jpg
26648.jpg
 
First, you could perhaps try using a proper RCA coaxial cable (75 ohms) rather than an RCA analog cable...
 
@pratik check that your prototyping board connects as you expect across this wider gap (red arrow). Some split into left/right halves, some connect across.

Screenshot 2026-03-17 at 15.48.40.png
 
Yes, sure. I have attached images of my hardware setup. I built the circuit provided in the GitHub repository, used an RCA connector, and connected it to a DAC. Then, I connected it to the amplifier and speaker.
Is this soldered or twisted? try soldering it on if its not.

1773779620721.png
 
Finally imported my first PEQ file from REW. It works. I love not having to key in the filter parameters.
I've been entertaining the possibility of implementing automated room correction or at least a simple test tone toolkit at some point in the relatively distant future, after I2S and SPDIF input has been dealt with.

Yes, sure. I have attached images of my hardware setup. I built the circuit provided in the GitHub repository, used an RCA connector, and connected it to a DAC. Then, I connected it to the amplifier and speaker.


View attachment 518379View attachment 518380
I would suggest double checking your dupont and direct wire connections. Breadboards are not known for their excellent contacts.

In other news, I2S output is the objective today. The plan is to extend the pin assignment configuration such that both pins and output types can be set.
 
In normal DSP operation, no, it will continue to function the same way. Setting the DSP to 0dB will give you the same settings on your operating system. But you can also set your operating system to 0dB and set the DSP to -18dB. In the first case, your signal chain needs other ways to reduce the volume to limit the impact on the speakers (like an integrated amplifier or a DAC with volume control).In the second case, if you don't have any other external means to limit the volume to protect your speakers (a DAC without volume control and a power amplifier), the DSP also acts as a limiter/protector.There's a third case where volume control can be applied at each stage (software/operating system, DSP, DAC, and amplifiers), but in that case, there's no particular problem.

Reading your post, a question comes to my mind. This might be a very silly question, but if the primary volume control is further down the signal chain, such as in the DAC/preamp/power amp, how would we ensure the volume level of the subwoofer? The DSPi Github page states that there is a dedicated sub output in order to avoid the need for a second DAC. But that would also mean that any volume control further down would not have any effect on it.

Or is there an easy solution to this problem?
 
I've been entertaining the possibility of implementing automated room correction or at least a simple test tone toolkit at some point in the relatively distant future, after I2S and SPDIF input has been dealt with.
Furthermore, who knows, just in case (let's be crazy), with a frequency response import function, the ability to have a higher pitch could be useful... but well, that's more complex to implement, and there are indeed software programs for that! haha ;)
So in the end, I wasn't as much of a dreamer as I'd imagined !? ;)
 
Reading your post, a question comes to my mind. This might be a very silly question, but if the primary volume control is further down the signal chain, such as in the DAC/preamp/power amp, how would we ensure the volume level of the subwoofer? The DSPi Github page states that there is a dedicated sub output in order to avoid the need for a second DAC. But that would also mean that any volume control further down would not have any effect on it.

Or is there an easy solution to this problem?
That's not a problem. The master volume (or limiter) at the DSPi level has no influence on the crossover parameters between the stereo SPDIF/I2S output and the PWM output in this case, or any other. It's simply a more secure way to manage the overall volume than a slider on an operating system.

Okay, sorry, I read your post a bit too quickly. So, in this case, "but if the primary volume control is further down the signal chain," it's more complicated. You have to be flexible. It's a special case. Without an external preamp, the principle in this case is to limit the volume of each element to the point of speaker saturation, then adjust the output gain at the DSP level. Therefore, volume control will only be done upstream and not at the output devices. As I have already said many times, the DSP also serves as a preamp.
 
Last edited:
I have just pushed a commit which addresses the buffer prefill bug (utilization is now stable), implements comprehensive SPDIF consumer pool statistics and raises the base system clock to 307.2MHz. The latter results in an integer PIO divider for I2S and SPDIF output, in addition to a few more DSP cycles.

If @Roland301 might be willing to retest the system latency with this commit, we can determine whether this bug had also been responsible for the varying latency.

I am going to continue testing the current build until satisfied that it is completely stable. At that point the next stop will be the aforementioned host-independent master volume control with a configurable startup volume and I2S output. :)
I must say, I'm impressed to the speed that you implement the new code! Even tho you might have a digital assistent, by the looks of it, you are in control. Thanks for supporting a future hobby project of mine ;)
 
Good evening,
I got it working now. Im on the 1.1.2 beta (RP2350) on windows 11. Its a great project! Here my current oservations:
- 96khz does not seem to work right now (distorted sound with toslink and coax)
- still some spdif buffer underruns reported via the statistics
- experienced some instabilities unter windows 11 with the sound output (requires more observation)

here a feature wish:
-can the on board LED be used to indicate playback?
-can we use the button to "round robin" or "toggle" through some presets? That way it could work even without using the software on Windows or Mac. The LED could flash after selection and indicate the preset number... just an idea ;-)
 
Good evening,
I got it working now. Im on the 1.1.2 beta (RP2350) on windows 11. Its a great project! Here my current oservations:
- 96khz does not seem to work right now (distorted sound with toslink and coax)
- still some spdif buffer underruns reported via the statistics
- experienced some instabilities unter windows 11 with the sound output (requires more observation)

here a feature wish:
-can the on board LED be used to indicate playback?
-can we use the button to "round robin" or "toggle" through some presets? That way it could work even without using the software on Windows or Mac. The LED could flash after selection and indicate the preset number... just an idea ;-)
Hello! Could you please confirm that you have been using this release? It was posted last night without an announcement, so may not have been spotted. I left it playing for several hours last night under macOS with frequent stops, starts source switches and was unable to provoke any underruns. I'll be testing Windows tonight.

While testing, did you perform any preset switching or save operations?

Regarding your questions, the LED and GPIOs will soon be user configurable. 96KHz isn't actively supported but I will be patching it once the current changes are complete.


Yes, sure. I have attached images of my hardware setup. I built the circuit provided in the GitHub repository, used an RCA connector, and connected it to a DAC. Then, I connected it to the amplifier and speaker.


View attachment 518379View attachment 518380
By any chance, have you been attempting to output 96KHz? That would explain your distorted audio.
 
Last edited:
I have just pushed a commit which addresses the buffer prefill bug (utilization is now stable), implements comprehensive SPDIF consumer pool statistics and raises the base system clock to 307.2MHz. The latter results in an integer PIO divider for I2S and SPDIF output, in addition to a few more DSP cycles.
Is this a change for the USB frames or just the SPDIF buffers?
 
Sorry if this noob comment is irrelevant

volume limiter setting - rescales the 0-100

separate maximum voltage setting for analog out

Obviously interrelated in functiin but separate "set it and forget it" in the UX

Wiim Ultra family as an example

Very useful as a "last ditch" speaker protection
 
I have spent the last few hours investigating behavior under Windows and the problems have become quite clear. It seems the handling of UAC1 feedback under Windows is much noisier than it is under macOS. This is in large part responsible for the underruns noticed by various users under Windows but not under macOS.

The core issue here is that asynchronous USB input operates on the basis of rate matching. The SPDIF consumer pool contains four buffers to absorb transient discontinuities but if the host's feedback is noisy (as in the case of Windows), the active buffers can drift in a dominant direction and in the absence of a corrective mechanism will eventually overrun or underrun.

To address this problem, I have implemented a simple servo, which is computed from buffer fill level and added to the computed feedback values. This servo is very mild (far quieter than the RP's own feedback jitter) and simply nudges the feedback output such that the consumer buffers are always held around 50% fill.

I have now been playing, stopping and starting content under Windows for almost three hours without encountering a single buffer underrun.

This appears to be the final piece of the puzzle! :)

Is this a change for the USB frames or just the SPDIF buffers?
The prefill and system clock changes are for SPDIF buffers and I2S/SPDIF respectively.
 
Hello! Could you please confirm that you have been using this release? It was posted last night without an announcement, so may not have been spotted. I left it playing for several hours last night under macOS with frequent stops, starts source switches and was unable to provoke any underruns. I'll be testing Windows tonight.

While testing, did you perform any preset switching or save operations?

Regarding your questions, the LED and GPIOs will soon be user configurable. 96KHz isn't actively supported but I will be patching it once the current changes are complete.



By any chance, have you been attempting to output 96KHz? That would explain your distorted audio.
Yes, I were using the latest Firmware and latest Windows application. And yes, via Roon I did upsample and immediatly I had distorions ... but once going back to 48/44.1 it was all ok.

But I think, I have another issue. My current main case is using it for smart loudness processing, for equipment, which nowadays does not have any loudness or treble/bass adjustments. But the loudness is not always enabling correctly (I should recognise more bass/treble). I see when enabling it that the processing power increases by 2-3% but no change in sound. Sometimes it does engage but in 80% of the cases not. I am wondering if I do not use the application correctly or if the loudness correction is not always switched in correctly into the signal path... ?

so far great work & fun to play with!!!
 
Yes, I were using the latest Firmware and latest Windows application. And yes, via Roon I did upsample and immediatly I had distorions ... but once going back to 48/44.1 it was all ok.

But I think, I have another issue. My current main case is using it for smart loudness processing, for equipment, which nowadays does not have any loudness or treble/bass adjustments. But the loudness is not always enabling correctly (I should recognise more bass/treble). I see when enabling it that the processing power increases by 2-3% but no change in sound. Sometimes it does engage but in 80% of the cases not. I am wondering if I do not use the application correctly or if the loudness correction is not always switched in correctly into the signal path... ?

so far great work & fun to play with!!!
The loudness compensation is host volume dependent. Once enabled, you need to decrease your Windows volume control. As the volume is decreased, the response is dynamically compensated.
 
The loudness compensation is host volume dependent. Once enabled, you need to decrease your Windows volume control. As the volume is decreased, the response is dynamically compensated.
Would it be possible in the future to couple it on the master volume of the pico or to add a encoder to make it variable. ...?
 
Would it be possible in the future to couple it on the master volume of the pico or to add a encoder to make it variable. ...?
Absolutely. This functionality is in the roadmap document and planned for the next major update.

EDIT: A little update. Windows feedback has proven stable, so I have decided to tighten a few screws. I have split the existing 4 SPDIF consumer pool buffers into 16 smaller ones, with the servo continuing to target a 2-buffer tolerance. Each buffer is now 48 samples in size (1ms at 48KHz), which results in a typical system latency of 8ms, with ±1ms of variation.

This required a minor refactor of my custom multi-instance SPDIF library, so I'm going to test it for a few hours under both macOS and Windows before committing.
 
Last edited:
DSPi Firmware v1.1.2b-hotfix is now available, with all of the bugfixes and stability refinements of the last few days. It should be extremely robust under both Windows and macOS.

DSPi Console v1.1.2b for macOS has also been released and introduces several major new functions.

1773908725202.png


Here is the list of changes:
  • Support for multiple devices, selectable from a list. Right-click to reconnect.
1773909058990.png
1773909086965.png


  • Parameters can now be copied and pasted between channels. Previous "right-click to rename" shortcut is now alt-click.
1773908196886.png


  • Quick access icons for Matrix Mixer, Crossfeed, Loudness Compensation, Stats for Nerbs and Settings. Left-click toggles Crossfeed and Loudness Compensation on or off. Right-click opens their respective configuration windows. Buttons for active functions are illuminated.
1773908282228.png
.
1773908634148.png


  • Filter response graph is now vertically resizeable in place by up to 100px to better show off your beautiful data. Scrolling over the vertical axis scale zooms the graph on that axis.
1773908355258.png


  • Filter response graph can now be popped out into a new window, leaving more space in the main application window for other elements.
1773908448276.png


  • Filter response graph can be configured to follow channel selection or be independent when popped out
1773908502788.png


  • Channel curves not belonging to the current Channel Editor page are displayed as dashed lines. This is configurable.
1773908565005.png


  • Scrolling over Channel Editor page values increments and decrements them
Expect a corresponding release for DSPi Console for Windows over the coming days. Once that is out of the way, our next stop is I2S output and user assignable GPIO controls! :)
 
Last edited:
Back
Top Bottom