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

[Tell]

It'll take a while for me before I can play around with this, but I'm closely following the development, really love these kinds of open source projects based on cheap but powerful hardware (well not powerful in an absolute sense, but for what's it's being used for)! Looking forward to have this replace my MiniDSP 2x4HD

Btw, is there any clipping indicator? And is it possible to rename the inputs and outputs?

 

[Weeb Labs]

It'll take a while for me before I can play around with this, but I'm closely following the development, really love these kinds of open source projects based on cheap but powerful hardware (well not powerful in an absolute sense, but for what's it's being used for)! Looking forward to have this replace my MiniDSP 2x4HD

Btw, is there any clipping indicator? And is it possible to rename the inputs and outputs?

Clipping is monitored but not yet implemented within the applications. Along with channel renaming, it will likely appear in the next hotfix update.

 

[jogi]

I am delighted to announce the release of DSPi Console v1.0.8 for macOS and DSPi Firmware v1.0.8. This is quite a major update and introduces several important new functions.

First, let's take a look at the main application window.

View attachment 510328

The channel naming scheme has now been revised for consistency and the sidebar can now display up to eight output channels. The dashboard continues to display tables for all channels, with stereo cards for SPDIF channels and mono cards for individual ones such as PDM. The Master Bypass button has also been revised.

All selection functionality works exactly as it did before; we simply have more channels to work with. Meters currently display output activity only for the first SPDIF pair but this will soon be revised.

Next, we have the brand new Matrix Mixer, accessible via the Tools menu.

View attachment 510337
View attachment 510330
This is a powerful tool with many useful functions and I have spent quite a number of hours agonizing over the UI design. I am quite pleased with the current iteration, though some later revisions may eventually be made.

The Routing section enables one to route any input channel(s) to any output channel(s). Each route has an individual gain control, along with the ability to invert the routed signal.

In the Output section, we have quick access to the same gain, delay and mute controls as those found in the main application window, with all states properly synchronized. Crucially, we also have the ability to fully enable or disable any desired channel(s). Disabled channels are not shown in the main application window's sidebar and they do not consume any system resources. The dashboard view will also hide their cards.

View attachment 510332 View attachment 510333

By default, only Input L and Input R are enabled and routed to Out 1 and Out 2 respectively. This helps to keep the main application window free of unused channels, hopefully renders it less intimidating for new users and conserves system sources.

View attachment 510334

The final row on the right side of the Matrix Mixer is the original PDM subwoofer output. You may have noticed the amber color of the routing and enable buttons. This brings us to the most significant enhancement present within today's update: dual core optimization.

Previously, Core 0 alone was responsible for all PEQ filter computations, while Core 1 simply handled the software DAC for our analog subwoofer output. This architecture was adequate for five channels but certainly not for eight. The solution was to move the processing for all but two output channels to Core 1, leaving Core 0 free with more resources for handling time sensitive tasks.


Core 1 operates in two modes; EQ Worker and PDM:

View attachment 510335

If output channels 3-8 are disabled (leaving 1 and 2 available on Core 0), the system behaves as it did prior to this update. We have a stereo SPDIF output and the PDM channel is no longer amber (can be enabled).

View attachment 510336

If any of channels 3-8 are enabled, the system disables PDM (amber and we have 8 fully digital SPDIF output channels.

This architecture delivers the best of both worlds; stereo SPDIF and PDM with 50 PEQ filters available or 8-channel SPDIF with 100 PEQ filters available. You decide!

That's all for today. I hope you enjoy the software and please do advise me of any bugs.

Links:
- DSPi Console v1.0.8 for macOS
- DSPi Firmware v1.0.8.

PS: DSPi Console v1.0.8 for Windows is on the way.

Hi,
thank you for your great work.
This is totally something that i was looking for, so that i can get rid of SoundSource (which I always had some issues with).
I've been testing it for couple days already.

Unfortunately the latest release (1.0.8) did break it for me.
I'm using Pico 2 with SPDIF Coax output.
In the console everything looks ok, I did check the new Matrix Mixer, everything looked correct there, try to change things, didn't help.
My DAC behaves like there is no coax connected.
After flashing back 1.0.7, everything works.

Also, do you prefer to get issues here on forum or rather on github?

 

[Weeb Labs]

Hi,
thank you for your great work.
This is totally something that i was looking for, so that i can get rid of SoundSource (which I always had some issues with).
I've been testing it for couple days already.

Unfortunately the latest release (1.0.8) did break it for me.
I'm using Pico 2 with SPDIF Coax output.
In the console everything looks ok, I did check the new Matrix Mixer, everything looked correct there, try to change things, didn't help.
My DAC behaves like there is no coax connected.
After flashing back 1.0.7, everything works.

Also, do you prefer to get issues here on forum or rather on github?

Ah, I neglected to mention that the SPDIF output pins have changed with this release. That is the cause of your trouble.

The new SPDIF pins are 6,7,8 and 9.
Pin 6 is SPDIF 1.

I must update the readme! GitHub does make it easier to track issues but I am happy to receive bug reports here.

 

[voodooless]

@Weeb Labs , any chance you can do jitter measurements? Since you use UAC 1 and the internal clock divider of the CPU to generate the sampling frequencies, it would be good to validate if this is actually good enough? I'm not super scared about the SPDIF output, because the receiver will recover and smooth the clock anyway. But when using I2S, this is a different story.

 

[Weeb Labs]

@Weeb Labs , any chance you can do jitter measurements? Since you use UAC 1 and the internal clock divider of the CPU to generate the sampling frequencies, it would be good to validate if this is actually good enough? I'm not super scared about the SPDIF output, because the receiver will recover and smooth the clock anyway. But when using I2S, this is a different story.

I will be taking a few measurements shortly. My scope's bandwidth isn't quite high enough to measure I2S clock jitter but I will see what can be done.

I'm not particularly concerned about jitter in general. Whether the chosen DAC is I2S or SPDIF, most will have a PLL. Jitter components from these MCUs will be dominated by VCO phase noise that's quite readily filtered.

 

[voodooless]

Whether the chosen DAC is I2S or SPDIF, most will have a PLL

No, most I2S DACs do not have a PLL. The only ones that have an internal ASRC are the higher-end ESS DACs.

 

[TurtlePaul]

The new SPDIF pins are 6,7,8 and 9.
Pin 6 is SPDIF 1.

Can you make SPDIF 1 deliver both to the new and old pins? Or do you need to release GP20 for something other functionality?

 

[Weeb Labs]

No, most I2S DACs do not have a PLL. The only ones that have an internal ASRC are the higher-end ESS DACs.

It might depend upon the class of DACs in question but most of the common ones like the PCM5102 and ES9038 do. Not an ASRC but just a PLL that effectively low passes VCO noise and divider modulation.

 

[Roland68]

It might depend upon the class of DACs in question but most of the common ones like the PCM5102 and ES9038 do. Not an ASRC but just a PLL that effectively low passes VCO noise and divider modulation.

In fact, the routines for jitter removal and digital signal conditioning are significantly better in most DACs for SPDIF coaxial/Tosling, AES, and USB, because this processing is handled in dedicated circuitry before the DAC chip itself. Only then is the signal passed to the DAC chip via I2S.

The external I2S signal usually bypasses this circuitry and goes directly to the I2S input of the DAC chip.

 

[voodooless]

It might depend upon the class of DACs in question but most of the common ones like the PCM5102 and ES9038 do. Not an ASRC but just a PLL that effectively low passes VCO noise and divider modulation.

Indeed, these have a PLL (some with ASRC, like the ES9038). I didn't even know the PCM5102A had a PLL, thanks for pointing that out But this is in no way common. DACs like AK4493Q (and others from the same series) do not have PLLs. Neither does the Ti PCM1795, nor the Cirrus AD1938, for instance. So it's quite a mixed bag.

Now, one could simply say: use one of the ones with a PLL for now . That would save time implementing a more advanced clocking system and spend it on more interesting features You can get a PCM5102A board for under €$ 2 at AliExpress, an ES9018K2M for below € 12... (just don't blame me when they are fake )

So you can effectively make an 8-channel DSP-enabled DAC with a 100+ SINAD for way under €$ 100 (or even under €$ 30 if you use the PCM), including PSU and a halfway decent enclosure. Amazing times!

 

[Weeb Labs]

Looking at some of the more typical mid-market options, I can indeed see that most lack a PLL and expect a master clock. If using one of these on my hat boards, an ASRC might be necessary.

 

[voodooless]

If you happen to do Jitter tests, please use 44.1 kHz sampling (or a multiple). It was fairly common for UAC 1.0 devices to have significantly higher jitter with that sample rate because the USB clock is 48 MHz, so a nice multiple of 48 kHz. Given that you PLL the clock from the CPU clock, this might not be an issue for you, though.

 

[Weeb Labs]

Can you make SPDIF 1 deliver both to the new and old pins? Or do you need to release GP20 for something other functionality?

The pins were primarily changed because there weren't enough usable pins adjacent to 20 and this places both SPDIF and PDM next to each other.

If you would prefer SPDIF 1 on pin 20, duplicating the output to it can certainly be on. I might make pins configurable at runtime so that the user can make this decision.

If you happen to do Jitter tests, please use 44.1 kHz sampling (or a multiple). It was fairly common for UAC 1.0 devices to have significantly higher jitter with that sample rate because the USB clock is 48 MHz, so a nice multiple of 48 kHz. Given that you PLL the clock from the CPU clock, this might not be an issue for you, though.

Yes, I will be sure to test this. The most practical approach seems to be the classic REW jitter test. I'll generate a master clock output, which should offer the clearest picture.

 

[TurtlePaul]

If you would prefer SPDIF 1 on pin 20, duplicating the output to it can certainly be on. I might make pins configurable at runtime so that the user can make this decision.

I don’t want to add to your list, I am just being lazy and the next update may just be a resolder but if duplicating the pins is one line of code, it would be appreciated.

 

[[IDC]Dragon]

Would this project be an option for SPDIF input? It’s also based on a pico mcu, and the list of needed components is small.

To which I proudly contributed.
Greetings!
(I un-lurked to say hi)

S/PDIF input forces its input rate, unless you can directly proceed with this (unlikely), further processing requires a sample rate converter.
Having an asynchronous sample rate converter in software is an unfortunate thing. When done properly it consumes about the performance of the Pico. In hardware, a chip like SRC4392 costs twice as much as the Pico board.

 

[Red_Red]

Great project! I've been waiting a long time for an equivalent to the "Nanodigi" (which hasn't been produced for ages and hasn't been replaced by MiniDSP). I have a feeling I've finally found the perfect solution for two to three times less money (all included)! Well done on this initiative!

If you were to produce a HAT board with four coaxial SPDIF outputs (75 ohms) and two SPDIF inputs (one coaxial and one optical), that would be even better! Are you planning something like that?

 

[Weeb Labs]

To which I proudly contributed.
Greetings!
(I un-lurked to say hi)

S/PDIF input forces its input rate, unless you can directly proceed with this (unlikely), further processing requires a sample rate converter.
Having an asynchronous sample rate converter in software is an unfortunate thing. When done properly it consumes about the performance of the Pico. In hardware, a chip like SRC4392 costs twice as much as the Pico board.

Thanks for your hard work!

The plan at the moment is to use the library's detected sample rate to trigger the same system clock frequency switch as the USB endpoints and then use a ring buffer with read feedback from fill level to clock the output SPDIF to that input by varying the PIO divider. I'm hoping to avoid an ASRC but it precludes the possibility of mixing inputs.

By the way, in future releases, I will be streamlining the firmware update mechanism. A copy of the most recent firmware will be bundled with the desktop applications, which will query the connected DSPi for its firmware version and prompt for an update if one exists. It will then handle the update automatically and provide a brief changelog. The applications themselves will also gain update functionality via the GitHub repository. This functionality will be fully configurable and opt-in, of course.

This should result in much smoother interactions on the user's part.

 

[Guerilla]

Is it based on CamillaDSP?

 

[xaxxon]

SPDIF, I2S and Bluetooth input are on the roadmap but for now, input is exclusively via USB Audio.

We've reached that magical sleepless 8 AM hour again, so I must get some rest. I will try to answer any pending questions before work, later in the morning.

Why isn’t there a low latency bit perfect system out there for WiFi connections?

What would it take to make that for a system like this? Basically just a virtual audio card driver for the OS and a UDP receiving app on the pi?

Something in the range of 200ms latency would be incredible.