• 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

If Windows level is 0 then there is no risk, unless I'm missing something.

Thanks for the suggestion but not sure I want to add another device in the chain. My setup is rather simple:

laptop > DSPi > DAC > preamp w/remote > power amp

I have 3 points where I can safely turn levels down before the music starts (w/o getting out of my chair!), just need to remember to do so. Since my typical listening level is pretty low the risk is also. I have another DAC w/remote I could use but I like that one where it is.

If you’re only using it for DSP/PEQ into a single output, your setup is solid. However, if you’re running multiple DACs feeding multiple channels, amps, and subwoofers, it won’t scale properly. In that case, you need a single master volume control upstream, typically your laptop, to keep all channels balanced.
 
....... However, if you’re running multiple DACs feeding multiple channels, amps, and subwoofers, it won’t scale properly. In that case, you need a single master volume control upstream, typically your laptop, to keep all channels balanced.
Yes, this is what I do in my multichannel system as shared in above post #1,555.

For digital USB control of the most-upstream Master Volume in digital music player JRiver MC on Windows PC, I use two of simple and robust USB dial volume controller, COOIDEA USB2.0 Volume/Track-Jump Controller, as shared in my post #931 on my project thread.
Fig34_WS00007502.JPG
 
Last edited:
And,,,
As I shared in my post #931 on my project thread, I use VB-AUDIO MATRIX as system wide audio routing center including ASIO, VASIO, VAIO as well as, if needed, all the other Windows sound I/O devices/software-tools (through WASAPI, direct sound, WDM, WDF, etc).

For my daily audio listening sessions with my SSD digital audio library and JRiver MC as music player, I use only ASIO plus VASIO64A routing for feeding digital music signal into DSP "EKIO" working as system-wide DSP center, and sending DSP-ed multichannel signals into OKTO DA8PRO.

In this daily music listening sessions, it is critically important avoiding any of unexpected and sudden intrusions of sound possibly given by Windows OS itself (OS's various chiming sounds, alert sounds, etc.) and/or other software including web browsers.

I always set, therefore, during my daily usual listening session, the Windows' default audio output device and the default audio communication device designating to not-in-use audio device(s) so that no sudden unexpected audio intrusion should come into my system-wide DSP Center "EKIO". (I mean never to designate Windows' default audio into ASIO and/or VASIO devices I use for my music listening sessions.) We can easily do it by Control Panel - Sound, and as double check safety measures, set in "Mute" in VB-Audio Matrix's relevant "routing grid cells".

In some rare situation, I may allow OS and/or other software to give sound intrusion into DSP "EKIO" by setting the default sound device designating VB-Audio's VAIO4, but in that case I carefully set beforehand the relevant "routing grid cells" in less than -20 dB gain.
WS1196.JPG


In any way, not only Windows Control-Panel-Sound-Settings but also VB-AUDIO Matrix's "Routing Grid Cells" can work nicely as "sound protection/safety measures/settings"; VB-AUDIO Matrix's "Routing Grid Cells" also can work as "system wide gain balancing center" for all of audio I/O routing.
 
Last edited:
DSPi replaced EKIO for me.
Nice to hear so.
May I ask about some details of your present audio setup using DSPi?

I (we?) would highly appreciate if you would kindly draw and share your total signal path diagram like the one I shared in my above post #1,555 in which I still use DSP "EKIO". Even your hand-drawn rough diagram/sketch will help a lot, I assume.

Furthermore, if you would be interested, you are cordially invited to my hosting remote thread entitled "Let's share diagrams (and photos) of our total physical audio system and the whole signal path, with a few words and/or links".
 
I had some spare time, so I had a go at a block diagram of the DSPi audio processes and came up with this:-
DSPi_Block_Diagram2.png

It's not as pretty as @Kingsnake 's diagram, but I think I got the detail more or less correct? The thing that I realise now is that Master Volume should probably be called Master Gain - most of the argument discussion would probably stop then :p

The other problem is with User Volume - this can be controlled by GPIO (remote, encoder etc.) USB and LG-SS.
  • While the others are "bidirectional" and can update each other, LG-SS is "unidirectional" - unless an IR Output to the LG TV is implemented to close the loop. That way when changing from USB input to LG-SS input the output could be muted and IR Volume-Up/Down commands sent until the levels synchronise, then un-mute the output.
  • With SPDIF/I2S unputs there is no problem - only the GPIO and USB influence the User Volume. Personally I would prefer to see an option to turn off USB volume control on non-USB inputs, so someone messing around on the USB host doesn't accidentally go full-volume for someone listening to an SPDIF input on headphones o_O
I mainly did this to try and sort my thoughts out, but I hope it helps generate some discussion - unfortunately I can't attached the original .odg Libre Office file. Looking at it, it's absolutely fecking mind-blowing that @Weeb Labs has got the RP2350 to do this much for so little cost. Assuming I got it right! ;)

Edit:- I didn't get it right! Added volume feed into leveller and loudness compensation. Also attached .pdf as @Salt mentioned.
 

Attachments

Last edited:
In Libre Office you can export a file as PDF.
 
Nice to hear so.
May I ask about some details of your present audio setup using DSPi?

I (we?) would highly appreciate if you would kindly draw and share your total signal path diagram like the one I shared in my above post #1,555 in which I still use DSP "EKIO". Even your hand-drawn rough diagram/sketch will help a lot, I assume.

Furthermore, if you would be interested, you are cordially invited to my hosting remote thread entitled "Let's share diagrams (and photos) of our total physical audio system and the whole signal path, with a few words and/or links".

No offense but that image is a little, busy. I don't want to clone it.

Its just the dspi, four 5102 dacs wired up. Just using two for now going to two amps unbalanced. 300hz 4th order xover between mechano23 and 12" subs that act as stands.

EKIO is very nice. But it either requires two audio interfaces, an interface with internal route-able loopback, or vb cable work around which I very much do no like using.
 
Last edited:
I had some spare time, so I had a go at a block diagram of the DSPi audio processes and came up with this:-
View attachment 530654
It's not as pretty as @Kingsnake 's diagram, but I think I got the detail more or less correct? The thing that I realise now is that Master Volume should probably be called Master Gain - most of the argument discussion would probably stop then :p

The other problem is with User Volume - this can be controlled by GPIO (remote, encoder etc.) USB and LG-SS.
  • While the others are "bidirectional" and can update each other, LG-SS is "unidirectional" - unless an IR Output to the LG TV is implemented to close the loop. That way when changing from USB input to LG-SS input the output could be muted and IR Volume-Up/Down commands sent until the levels synchronise, then un-mute the output.
  • With SPDIF/I2S unputs there is no problem - only the GPIO and USB influence the User Volume. Personally I would prefer to see an option to turn off USB volume control on non-USB inputs, so someone messing around on the USB host doesn't accidentally go full-volume for someone listening to an SPDIF input on headphones o_O
I mainly did this to try and sort my thoughts out, but I hope it helps generate some discussion - unfortunately I can't attached the original .odg Libre Office file. Looking at it, it's absolutely fecking mind-blowing that @Weeb Labs has got the RP2350 to do this much for so little cost. Assuming I got it right! ;)

Edit:- I didn't get it right! Added volume feed into leveller and loudness compensation. Also attached .pdf as @Salt mentioned.
That's a very nice graph. Well done! The only missing component appears to be the crosspoint insertion gains.
 
I received an STM32H723 a few days ago (thanks to project supporters) and have pushed an initial port. This board offers many advantages over the RP2350 and is only slightly more expensive on AliExpress. Among those advantages are a faster CPU, much higher resolution feedback, hardware SPDIF RX and a double precision FPU.

To be clear, this port is a side project. While it would be nice to fully support the STM32, the Pico is my priority. :)
 
I received an STM32H723 a few days ago (thanks to project supporters) and have pushed an initial port. This board offers many advantages over the RP2350 and is only slightly more expensive on AliExpress. Among those advantages are a faster CPU, much higher resolution feedback, hardware SPDIF RX and a double precision FPU.

To be clear, this port is a side project. While it would be nice to fully support the STM32, the Pico is my priority. :)
Phil's lab at YouTube has several videos on DSP with stm32, mostly for guitar pedals etc, but they might be of interest. Also, and I think this is his strength, on how to lay down the PCBs, specifically for audio mixed signals.
 
I have just pushed DSPi Firmware v1.1.4-beta2 and DSPi Console v1.1.4-beta2 for macOS. Console for Windows will be updated shortly but the current release is compatible. This beta addresses some additional longstanding bugs, while introducing several quality of life changes.

Here is the full list:
  • Loudness Compensation algorithm is now accurate at 100% intensity
  • Host volume control no longer affects device volume and crashes when SPDIF input mode selected *
  • Factory defaults no longer apply high pass filters to output channels
  • PCM5102A DAC (and potentially others) no longer exhibit auto-mute pops and clicks during quiet audio, play/pause and scrubbing **
  • Click-free host and master volume control
  • Per-band bypass control
* When switching from USB to SPDIF input, the most recent host volume setting is retained. This will be addressed shortly.
** This is not a DSPi bug; it is a design flaw of the PCM5102A that we suppress with some clever 32-bit trickery to keep the DAC unmuted


I expect to include LG Sound Sync support in the next beta. As always, bug reports can be submitted either here, on GitHub or Discord (many helpful people there).

Phil's lab at YouTube has several videos on DSP with stm32, mostly for guitar pedals etc, but they might be of interest. Also, and I think this is his strength, on how to lay down the PCBs, specifically for audio mixed signals.
Thanks for that! I stayed up far too late working on the port, last night. It's effectively almost complete at this point, with only flash operations remaining to be implemented. :)
 
Last edited:
Will the STM have enough processing power to allow decoding of 5.1 audio over SPDIF and/or support for FIR filters?
 
Will the STM have enough processing power to allow decoding of 5.1 audio over SPDIF and/or support for FIR filters?
AC3 surround decoding would occupy about 5-8% of the available cycles on the STM32. I have been further investigating the possibility of implementing it on the RP2350 and it now looks feasible but will occupy about 20% of a core.

The STM32 will manage about 6500 FIR taps in total.
 
A quick update on the STM32H723 port. This board offers approximately five times the DSP headroom of the RP2350. With 40 PEQ filters, loudness compensation, crossfeed and volume levelling all active, CPU utilisation is just 10%. The STM is quite a monster of an MCU!
 
So, your experience may vary but I just spent a while (hours) trying to get my app (DSPiCliRemote) and the beta1 (and 2) DSPi-Console-Windows to run in my Windows 10 NUC. I recently (like a week ago) reformatted it for Windows 10 pro so it's very clean. I tried Zadig and WinUSB but reverted to the default WinUSB configuration for solving. Note the audio part seems ok (though I didn't test it). This is strictly the console.

What I found was that it was crashing when trying to find libusb-0.1.dll while trying to create the context. I don't know why it couldn't 'find' the DLL but this was consistent for both of our apps (actually in Beta 2 I think it's not there). The symptom was the app starting up and never displaying. Short hourglass then nothing.

The solution was to use a dll other than the current project-defined nuget LibUsbDotNet dictated DLL. I think I first tried the latest release of LibUsbDotNet to see if it was fixed. Instead, I used the one here: https://github.com/libusb/libusb/releases and it ran flawlessly. Both with the DSPiConsole and my app. It lives in the MinGW64 folder.
 
So, your experience may vary but I just spent a while (hours) trying to get my app (DSPiCliRemote) and the beta1 (and 2) DSPi-Console-Windows to run in my Windows 10 NUC. I recently (like a week ago) reformatted it for Windows 10 pro so it's very clean. I tried Zadig and WinUSB but reverted to the default WinUSB configuration for solving. Note the audio part seems ok (though I didn't test it). This is strictly the console.

What I found was that it was crashing when trying to find libusb-0.1.dll while trying to create the context. I don't know why it couldn't 'find' the DLL but this was consistent for both of our apps (actually in Beta 2 I think it's not there). The symptom was the app starting up and never displaying. Short hourglass then nothing.

The solution was to use a dll other than the current project-defined nuget LibUsbDotNet dictated DLL. I think I first tried the latest release of LibUsbDotNet to see if it was fixed. Instead, I used the one here: https://github.com/libusb/libusb/releases and it ran flawlessly. Both with the DSPiConsole and my app. It lives in the MinGW64 folder.
I encountered this when testing under Windows 10 some time ago. The solution is to ensure that you have the Visual C++ Redistributable installed.
 
Back
Top Bottom