• 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

For me, as you've probably gathered, it's the ergonomics rather than the color choices that raises questions. Overall, the design is very pleasant. But if it's nice, it also needs to be effective. So, okay, improving the contrast is good, but eliminating redundancies, simplifying the interface, making it more efficient, and more technically in line with what's already out there (and which has proven its effectiveness), seems more important to me than a clunky, neon-lit design (which isn't entirely the case here, thankfully).

There's no shame in drawing inspiration from what's already been done. And if you want to be a pioneer, you shouldn't sacrifice the technical foundation; that is, understand the ins and outs of why you're creating something.

As was my question about volume management, my question about the number of decimal places for delays and gains isn't random; it stems from years of experience with dedicated software, from rew to vituixcad, manipulating multiple DSPs, and fine-tuning DIY speakers... the same goes for delays and gain (on outputs)... which frankly don't need to be a constantly adjustable variable, but rather something that, at best, is rarely adjusted. [Besides, I don't really see the point of delay on inputs except to compensate for a discrepancy between an audio track and the video images... but anyway... generally, this is compensated for through the host software, the television, or something else, but not at the DSP level].

That being said, there are still some innovations here, such as on-the-fly headphone correction and crosstalk reduction—very useful features for those who will use them or can already use them.

But that's why I asked a few days ago if this project wasn't exceeding Troy's ambitions. It's clear that his initial focus was on the general user experience (autoEQ for headphones, dynamic range compensation, etc.), but it seems to be adapting gradually (and quite willingly, I must say) to other, more technical and ambitious uses (ADAT, crossover management for DIY speakers). This desire to satisfy users but also to push himself further, striving to create an "Audio Swiss Army knife", is remarkable. To him, I would say to think clearly, to take a step back, to be willing to question some of his choices without sacrificing his creativity. But also to consider technicality, practicality, ergonomics, and ease of use, and then illuminate the whole thing with a relevant design.
 
Last edited:
I have just released DSPi Firmware v1.1.3 Beta 4. This release enables support for 96KHz input up to 24-bit and fixes the I2S/SPDIF output switching. All I2S outputs are now correctly clock aligned regardless of the order in which they were enabled. This eliminates the distorted output which previously resulted from a very slight initial clock misalignment. :)

@Lastafahrer: I encourage you to give this release a try. It was tricky to debug without the ability to actually listen to the output but measurements of all I2S data outputs indicate correct alignment regardless of selection order. Channel packing order has also been corrected, so left and right channels are no longer reversed.

There may be some slight instability when continuously switching output types. This will be corrected shortly but I need to work from the top down.

PSA: It occurs to me that if you have an I2S DAC connected to a given data output, it is essential always to mute your amplifier prior to switching that output to SPDIF. Otherwise, you will most likely be greeted with noise at full scale. This is unavoidable, as SPDIF data is completely unintelligible to an I2S DAC. I may implement an optional warning and confirmation prompt in DSPi Console for this purpose.

@Luffy: If you take a look at the output overhaul branch on the repository, you will see the recent commits that I pushed to fix 96KHz at 24-bit. These may be helpful to you.
Just updated DSPi to the latest version for MacOS.
I2S works great up to 96 kHz incl. all kind of GPIO assignments!
BTW: What is the MCK Multiplier for?
Please don't forget to display the number of bits and sample rate for the audio in the main DSPi window :)
 
Please don't forget to display the number of bits and sample rate for the audio in the main DSPi window :)
Sorry "Sinic-wall", I obviously have nothing against you, but that's precisely the "general use" example I was talking about... but frankly, it's not the console of a DSP that should display that, but only the playback software... but why not, the French have an expression for that, "Plus on est de fous, plus on rit" but sometimes it's a bitter laugh...
 
Great to read, that you have nothing against me ;-)
There are so many ways to change the sample rate.
Right now Spotify plays 16 bit/44,1 kHz and my DAC shows 96 kHz. Which sample rate sees DSPi?
 
Great to read, that you have nothing against me ;-)
There are so many ways to change the sample rate.
Right now Spotify plays 16 bit/44,1 kHz and my DAC shows 96 kHz. Which sample rate sees DSPi?
If you're on Windows, you must have configured your audio output to 96kHz... and not as a variable output... that's why your DAC is giving you incorrect information... well, not entirely incorrect since Windows has upsampled the original format to 96kHz...
 
Sorry, I'm on MacOS and my DAC shows the correct sample rate.
As you can see the sample rate of the playback music SW is in this case not really helpful.
However, you didn't answer my question ;-)
 
Certainly, but that doesn't change my answer that it's not the DSP's job to display the current sampling rate, the bits, or why not a pinup girl dancing on the screen to the rhythm of the music... since the DSP will upsample or downsample the initial format anyway in order to apply its filters, EQs, etc.
 
I‘m glad that you are not deciding the roadmap of this project, or did I miss something?

One of the most useful things of my RME ADI-2 Pro FSR is the state overview display, which shows the sample rates and bits of each input.
This becomes in particular handy once you have a sample rate converter in combination with different clock sources that can be individually assigned to the input signals. Sometimes the DSP gets deactivated or no signal at all is at the digital or analog outputs.
A brief look at the state overview display and you know the root cause of the problem.
Another solution would be an additional window that provides this information similar to the „stats for nerds“ window.
1775802513465.png

We have soon a situation with multiple inputs that all carry its own sample rates (USB, SPDIF, I2S).
How to handle the clock for various outputs (USB, SPDIF, I2S)?
I‘m sure Troy is aware of this and may have already a solution in mind.
 
Last edited:
We now have a master volume control, while input preamps have been made per-channel with optional linking and moved to their respective channel pages.

View attachment 523362 View attachment 523372

A new setting has also been added to determine whether the master volume level saved to a given preset is applied when that preset is loaded.


If you are using Windows, please bear in mind that Firmware v1.1.3 will require the Console v1.1.3 update, which is not yet available. There were many changes in v1.1.3 which are incompatible with earlier Console versions.

DSPi Console v1.1.3 for Windows should be released this weekend.
Thank you so much :)))
 
I‘m glad that you are not deciding the roadmap of this project, or did I miss something?

One of the most useful things of my RME ADI-2 Pro FSR is the state overview display, which shows the sample rates and bits of each input.
This becomes in particular handy once you have a sample rate converter in combination with different clock sources that can be individually assigned to the input signals. Sometimes the DSP gets deactivated or no signal at all is at the digital or analog outputs.
A brief look at the state overview display and you know the root cause of the problem.
Another solution would be an additional window that provides this information similar to the „stats for nerds“ window.
View attachment 523552
We have soon a situation with multiple inputs that all carry its own sample rates (USB, SPDIF, I2S).
How to handle the clock for various outputs (USB, SPDIF, I2S)?
I‘m sure Troy is aware of this and may have already a solution in mind.
Yes, sorry, I understand the meaning of your request better now.
 
the phase inversion.
In matrix mixer the ”inv“ is somewhat in the wrong place and IMHO belongs to the settings below.
Looking into this issue in particular, I believe Invert is actually in the only appropriate place at the moment. The Invert function is applied per crosspoint rather than per output channel and a single output channel may have multiple channels with discrete inversion states routed to it.
 
The “official” custom boards will include an ESP32 to handle the WiFi interface
I'm not sure how it would fit your longer term vision, but would you be planning to do something like this, only refined for the DSPi use-case?


If you're doing WiFi control, then a simple display could probably be squeezed into RAM as well(?). Personally I see no need for a touch-screen on HiFi units, but YMMV. Some small round-screen modules also come with a rotating bezel, although quality of implementation varies.


I'm looking forward to the official DSPi boards, but I'm happy to wait for a fully-baked solution :)
P.S. I'm old enough to have hankered after the Philips VR-969 VCRs. Futuristic! :facepalm:
 
I'm not sure how it would fit your longer term vision, but would you be planning to do something like this, only refined for the DSPi use-case?


If you're doing WiFi control, then a simple display could probably be squeezed into RAM as well(?). Personally I see no need for a touch-screen on HiFi units, but YMMV. Some small round-screen modules also come with a rotating bezel, although quality of implementation varies.


I'm looking forward to the official DSPi boards, but I'm happy to wait for a fully-baked solution :)
P.S. I'm old enough to have hankered after the Philips VR-969 VCRs. Futuristic! :facepalm:
Direct display support within DSPi is unlikely, as the RAM usage would be very high. ESP32 devices such as the ones that you posted would make excellent local controllers, as they have support for BLE, which is a very lightweight protocol. The official board will include an ESP32 or similar cheap SoC to handle WiFi and web UI.

I purchased one of these pendant units last month and will be using it to experiment with BLE control.

1775841801190.png
 
I'm not sure how it would fit your longer term vision, but would you be planning to do something like this, only refined for the DSPi use-case?


If you're doing WiFi control, then a simple display could probably be squeezed into RAM as well(?). Personally I see no need for a touch-screen on HiFi units, but YMMV. Some small round-screen modules also come with a rotating bezel, although quality of implementation varies.


I'm looking forward to the official DSPi boards, but I'm happy to wait for a fully-baked solution :)
P.S. I'm old enough to have hankered after the Philips VR-969 VCRs. Futuristic! :facepalm:
I'm planning using this one

ESP32 LVGL Ar-duino IDF 1.28 inch 240*240 circular knob rotary switch round IPS tft lcd display with WiFi

Hopefully it won't be too difficult to integrate it preferably through UART (or i2c with additional bridge controller)
 
Last edited:
Direct display support within DSPi is unlikely, as the RAM usage would be very high. ESP32 devices such as the ones that you posted would make excellent local controllers, as they have support for BLE, which is a very lightweight protocol. The official board will include an ESP32 or similar cheap SoC to handle WiFi and web UI.

I purchased one of these pendant units last month and will be using it to experiment with BLE control.

View attachment 523658
A desktop alternative: https://shop.pimoroni.com/products/presto?variant=54894104019323
 
Hopefully it won't be too difficult to integrate it preferably through UART (or i2c with additional bridge controller)
I already coded a proof of concept for DSPi with UART support to communicate with an ESP32-LCD-1.47 MCU/display. It works and shows the levels. I2C may give more trouble since ESP-IDF just made some breaking changes to the I2C-slave API. UART/I2C support is on the roadmap.

I fully agree here with Troy's vision of using an ESP32 as a WiFi interface / remote / additional console display.
 
So ESP32 would not be in the audio streaming path, just peripheral interfaces?
 
So ESP32 would not be in the audio streaming path, just peripheral interfaces?
In my view, the only scenario where the ESP32 would make sense in the audio streaming path would be as I2S to USB host interface. This seems not to be easy today, but it might be in the future.
 
In my view, the only scenario where the ESP32 would make sense in the audio streaming path would be as I2S to USB host interface. This seems not to be easy today, but it might be in the future.
Agreed. I am currently refactoring in order to modularize the input path. This will facilitate not only SPDIF, I2S and ADAT input but also the use of an ESP32-C5 as the USB audio interface if desired.
 
First of all thank you for this project! Second of all, I'm not sure what black magic is in there, but this jankiness I have here has no business sounding this good. I used Rew and my phone as a mic to do some rough room correction in order to reduce the boominess of a few frequencies and on that pcm5102 I added a lc low pass filter, beefed up the filtering after its voltage regulators and swapped the cheap microphonic ceramics on the output rc low pass filter with film ones. It's truly amazing what a few bucks in components can achieve.
but hmm, i2s input you say, this would mean I can apply room correction on my turntable in the future. I'm wondering if it would be possible to use external active crystals for the i2s clocks, that would be a good way to have extremely stable communication with virtually no jitter.
 

Attachments

  • 20260411_025023.jpg
    20260411_025023.jpg
    192.6 KB · Views: 122
Last edited:
Back
Top Bottom