Introducing DSPi | A powerful, user friendly and open source DSP for less than a cup of coffee

[Pouyoux]

Great project, clearly filling lots of users needs (handling a 2.1 setup with only a stereo DAC is a really nice feature) with cheap hardware

I'm planning to try DSPi with a NVIDIA Shield.
@Weeb Labs : Do you plan to add a remote/network console ?

I'm currently using CamillaDSP and it's very handy to be able to do DSP changes from my desktop PC on the fly.

 

[Luffy]

Hi @Weeb Labs ,
I tried modifying your firmware code from v1.0.7 along with the windows-console 1.0.5. But here are the results as you the can see in the image, the input and output arent being reflected. We tried along with the changes you mentioned me for 96khz.

( If memory serves, the only problem with 96KHz input at the moment is the USB descriptor packet size configuration and the endpoint stride type. If you increase .wMaxPacketSize to 582 within .core under .ep1_24 in usb_descriptors.c, that will enable 96KHz at 16-bit. For 24-bit, you will need to compute stride type per endpoint within usb_device.c in order to avoid overflowing the USB controller's 4096 bytes of DPRAM.)

Could you please help me out with this ?

 

[Red_Red]

Hi @Weeb Labs ,
I tried modifying your firmware code from v1.0.7 along with the windows-console 1.0.5. But here are the results as you the can see in the image, the input and output arent being reflected. We tried along with the changes you mentioned me for 96khz.

( If memory serves, the only problem with 96KHz input at the moment is the USB descriptor packet size configuration and the endpoint stride type. If you increase .wMaxPacketSize to 582 within .core under .ep1_24 in usb_descriptors.c, that will enable 96KHz at 16-bit. For 24-bit, you will need to compute stride type per endpoint within usb_device.c in order to avoid overflowing the USB controller's 4096 bytes of DPRAM.)

Could you please help me out with this ?

Personally, I'm not a coder at all, so I don't know if my answers will be helpful.

But just looking at the image attached to your post: you need to choose "libusb_win32" and not "WinUSB" in Zadig's dropdown list... and the firmware version must match the console version... (firmware N°XYZ, console N°XYZ)

As for the rest, I understand that support for 24-bit/96kHz could only be implemented on future I2S, SPDIF, or ADAT inputs... but not via USB...

 

[Tell]

The biggest question is why? 96kHz won't give you any audible gains, just more processing power, bandwidth and storage used for no reason whatsoever.

 

[Weeb Labs]

Hi @Weeb Labs ,
I tried modifying your firmware code from v1.0.7 along with the windows-console 1.0.5. But here are the results as you the can see in the image, the input and output arent being reflected. We tried along with the changes you mentioned me for 96khz.

( If memory serves, the only problem with 96KHz input at the moment is the USB descriptor packet size configuration and the endpoint stride type. If you increase .wMaxPacketSize to 582 within .core under .ep1_24 in usb_descriptors.c, that will enable 96KHz at 16-bit. For 24-bit, you will need to compute stride type per endpoint within usb_device.c in order to avoid overflowing the USB controller's 4096 bytes of DPRAM.)

Could you please help me out with this ?

I would suggest using the most recent firmware release with Windows support, as that is the one to which my advice pertained.

The biggest question is why? 96kHz won't give you any audible gains, just more processing power, bandwidth and storage used for no reason whatsoever.

This is why 96KHz has always been an afterthought in development, if not eliminated altogether. It is an awful waste of resources; especially when said resources are not abundant!

 

[RandomEar]

The biggest question is why? 96kHz won't give you any audible gains, just more processing power, bandwidth and storage used for no reason whatsoever.

It's somewhat useful if you work with mixed formats in your OS, like 44.1 + 48 + 96 kHz or some variation of at least two of them. I've checked the Windows upsampler myself and results for 44.1 -> 48 kHz are fine, but the output for 44.1 -> 96 kHz is simply cleaner (more info about this topic in this thread). It's extremely unlikely to be audible, but peace of mind is worth something. Also, you will do more processing on the data with the Pico, so a "grassy" noise floor / distortion profile coming into the DSP definitely isn't advantageous.

As a storage format outside of music production environments, 48 kHz 24 bit is pretty much all you'll ever need. For up-/down-/resampling, it can make sense to have a little bit of a buffer. Upmixing to 64 kHz would probably be fine, too, but it's rarely supported. If you only have either exclusively 44.1 or exclusively 48 kHz source material, the current implementation is totally fine.

 

[Tell]

It's somewhat useful if you work with mixed formats in your OS, like 44.1 + 48 + 96 kHz or some variation of at least two of them. I've checked the Windows upsampler myself and results for 44.1 -> 48 kHz are fine, but the output for 44.1 -> 96 kHz is simply cleaner (more info about this topic in this thread). It's extremely unlikely to be audible, but peace of mind is worth something. Also, you will do more processing on the data with the Pico, so a "grassy" noise floor / distortion profile coming into the DSP definitely isn't advantageous.

As a storage format outside of music production environments, 48 kHz 24 bit is pretty much all you'll ever need. For up-/down-/resampling, it can make sense to have a little bit of a buffer. Upmixing to 64 kHz would probably be fine, too, but it's rarely supported. If you only have either exclusively 44.1 or exclusively 48 kHz source material, the current implementation is totally fine.

Yeah I've never really bothered by anything over 48kHz, with the vast majority of stuff being 44.1kHz. The only peace of mind I need is that I'm certain I don't hear any difference between that and stuff above it, and not any potential resampling issues either.
So yeah I don't care for 96kHz, and it's nice to hear developers not going overkill just because people ask for it

 

[Luffy]

Personally, I'm not a coder at all, so I don't know if my answers will be helpful.

But just looking at the image attached to your post: you need to choose "libusb_win32" and not "WinUSB" in Zadig's dropdown list... and the firmware version must match the console version... (firmware N°XYZ, console N°XYZ)

As for the rest, I understand that support for 24-bit/96kHz could only be implemented on future I2S, SPDIF, or ADAT inputs... but not via USB...

thank you @Red_Red

 

[Luffy]

Hey @Weeb Labs
we will try with the latest console : DSPi-Console.v1.1.2b.Win.x64.zip

 

[john61ct]

96kHz would only serve marketing

Make it defeatable state upfront how much it reduces taps length / count and let those who want it buy lots more units - bit of "stupid tax"

 

[Red_Red]

I share your opinion, but at the same time I think that with a setup like this one, it would still be possible to get something out of it!

But the firmware would have to make it possible (that is, to be able to work directly with 24/96 formats) and perhaps also to optimize the DSPI's operation (distribute the cores) or to have the option of dedicating them to specific tasks... In this implementation, we can imagine one Pico dedicated to the inputs with its filtering (room or headphone correction) and the two Picos connected to it handling only the output filtering... And I imagine that volume management would be just a tiny bit more complicated, but that doesn't seem insurmountable.

 

[john61ct]

YES. I am not a DIYer with hardware or coding, but that is EXACTLY what I am after when it proves possible - not higher resolution but using multiple DSPi for different "layers"

besides "stereo signal system wide" vs per-amp-output-channel levels e.g per-speaker "as anechoic as possible"

I strongly believe the UIs for "ad-hoc user adjust" (at MLP) vs FR-only room correction vs crossovers / bass management, phase/time tuning vs FR-only

should be separate, even using completely different software per function.

Even if there is no coordination between the DSPi units.

Of course there may be a point where "DSPing the DSP" results in audible degradation...

 

[Weeb Labs]

Great project, clearly filling lots of users needs (handling a 2.1 setup with only a stereo DAC is a really nice feature) with cheap hardware

I'm planning to try DSPi with a NVIDIA Shield.
@Weeb Labs : Do you plan to add a remote/network console ?

I'm currently using CamillaDSP and it's very handy to be able to do DSP changes from my desktop PC on the fly.

Thank you! I intend to support IR remote, external GPIO control, BLE (on the W boards) UART and I2C interfaces.

The “official” custom boards will include an ESP32 to handle the WiFi interface, as the Pico’s WiFi driver occupies quite a lot of RAM. I will be experimenting to see how much can be shaved off, however.

 

[Fred H]

Thank you! I intend to support IR remote, external GPIO control, BLE (on the W boards) UART and I2C interfaces.

Please consider RF remote if possible. I find it frustrating to position my remote in just the right place so the IR signal goes through the perforated metal sheet that my miniDSP is behind; this is impossible if I sit off to the side, of course.

 

[Kingsnake]

Thank you! I intend to support IR remote, external GPIO control, BLE (on the W boards) UART and I2C interfaces.

The “official” custom boards will include an ESP32 to handle the WiFi interface, as the Pico’s WiFi driver occupies quite a lot of RAM. I will be experimenting to see how much can be shaved off, however.

Hi Troy,

With the ESP32 handling WiFi, will DSPi move toward a clear split where Pico handles all DSP and ESP32 handles control/UI only, or will some functionality overlap?

For basic controls like volume, mute, source switching, do you see those being handled on the ESP32 side, or remaining inside DSPi on the Pico?

Is the long-term goal for DSPi to operate fully headless, controlled entirely over network/remote without needing a PC at all?

With remote control and custom boards now in scope, do you see DSPi evolving into a standalone DSP hub (with inputs and switching), or staying as a focused DSP core that other systems build around?

Once inputs like SPDIF/I2S are added, will DSPi operate from a single selected input clock (typical source selection), or are you considering handling multiple clock domains?

How are you planning to draw the line to avoid feature creep while still adding things like WiFi, remote control, and custom hardware?

 

[Weeb Labs]

Hi Troy,

With the ESP32 handling WiFi, will DSPi move toward a clear split where Pico handles all DSP and ESP32 handles control/UI only, or will some functionality overlap?

For basic controls like volume, mute, source switching, do you see those being handled on the ESP32 side, or remaining inside DSPi on the Pico?

Is the long-term goal for DSPi to operate fully headless, controlled entirely over network/remote without needing a PC at all?

With remote control and custom boards now in scope, do you see DSPi evolving into a standalone DSP hub (with inputs and switching), or staying as a focused DSP core that other systems build around?

Once inputs like SPDIF/I2S are added, will DSPi operate from a single selected input clock (typical source selection), or are you considering handling multiple clock domains?

How are you planning to draw the line to avoid feature creep while still adding things like WiFi, remote control, and custom hardware?

The plan is for the RP2040/2350 to continue to handle control and DSP. Feature creep will be addressed in the form of control interfaces that give the user control over all parameters if they desire it.

For example, the WiFi connectivity on the official board will not rely upon a purpose built interface. It will simply be an ESP32 (or similar) on the same board, communicating via the same general purpose I2C interface that users will likely employ for various other purposes as well. DSPi will remain a standalone solution but all parameters and commands will be exposed so that other developers or DIY oriented users can implement it in a wide variety of projects.

Regarding clocks, this really depends upon what I can reasonably get away with. At the very least, a single selected input clock. In the case of I2S where DSPi is a slave, it will input and output data on word and bit clock edges, without the need to handle much clocking internally. The plan is to implement at least one ASRC, however.

 

[MCH]

Once you use a esp32 for wifi, check the C5 out, it could make a more capable USB audio bridge.
Check jmf11 progress here:

Post in thread 'the new ESP32-C5 and P4 support 16 channel 32 bit TDM in full duplex' https://www.audiosciencereview.com/...-32-bit-tdm-in-full-duplex.64332/post-2562480

 

[john61ct]

So, only certain esp32 units act as a USB Host as with a PC, right?

Google says S2 and S3...

 

[Kingsnake]

The plan is for the RP2040/2350 to continue to handle control and DSP. Feature creep will be addressed in the form of control interfaces that give the user control over all parameters if they desire it.

For example, the WiFi connectivity on the official board will not rely upon a purpose built interface. It will simply be an ESP32 (or similar) on the same board, communicating via the same general purpose I2C interface that users will likely employ for various other purposes as well. DSPi will remain a standalone solution but all parameters and commands will be exposed so that other developers or DIY oriented users can implement it in a wide variety of projects.

Regarding clocks, this really depends upon what I can reasonably get away with. At the very least, a single selected input clock. In the case of I2S where DSPi is a slave, it will input and output data on word and bit clock edges, without the need to handle much clocking internally. The plan is to implement at least one ASRC, however.

Thanks for the detailed explanation, that clears things up nicely. The modular approach with DSPi staying as the core and exposing control for external interfaces makes a lot of sense. It sounds like a solid way to keep flexibility without overcomplicating the platform. Looking forward to seeing how it develops.

 

[somebodyelse]

So, only certain esp32 units act as a USB Host as with a PC, right?

Google says S2 and S3...

You also need a UAC1 and/or UAC2 host driver depending on which DAC you want to connect it to.
https://github.com/Averyy/esp-uac2-host is a work-in-progress trying to do this for the S3. Its research doc has some info on alternatives that only support UAC1. There's also the problem of device quirks where they don't quite follow the standard and need a workaround - there are quite a lot of these in the linux UAC2 source.