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

[mikessi]

Each SPDIF handles

Yes. The audio outputs are digital SPDIF so that the user can choose their own DACs.

each SPDIF handles only 2 ch?

 

[bmc0]

While needing not so many cycles as a true FIR filter, it does need about twice the memory.

I hadn't thought about the memory requirements, but you are correct.

Turns out I made a mistake. The impulse is truncated after 2^(N+1) samples, not 2^N. A filter with 2^(N+1) taps then requires only 2^(N+1)-3 samples for the delay lines in the case of complex conjugate poles.

 

[kwas]

Excellent project worthy of support! One question, would this be recognized in Picore player as a USB audio device?

Thanks!

@Weeb Labs any thoughts on this?

Thanks!

 

[Weeb Labs]

Each SPDIF handles


each SPDIF handles only 2 ch?

Yes. The channel configuration is consists of four pairs of two channels. When I2S output is implemented, TDM8 also be possible.

@Weeb Labs any thoughts on this?

Thanks!

I haven't personally tested this but as the DSPi is a standard UAC1 device, it should be supported by any platform that implements USB audio.

 

[Kingsnake]

Please release the update windows console. I can't wait to try the new firmware. Thank you for the hard work.

 

[Sonic-Wall]

1.10V is the stock voltage for the Pico 2, which is ordinarily clocked at 150MHz. It is possible that your copy requires a little more for a 288MHz overclock (1.15V or 1.20V), so I'm going to send you a build with a slight voltage adjustment.

Other than a defective board, that is the most likely reason for the behavior that you've been seeing. I've not run into this on three tested RP2350s and nobody else has reported a similar issue, so it's quite odd.

I've update now my MacOS to 15.7.4 and I have still the problem that Pico 2 disappears from the Finder after connecting with the DSPi Console.
I also tried to switch back to my Pico 2040 but it always showed up as the RP2350 in the Finder even after installing the FW for the Pico 2040. Hence the Pico couldn't connect at all to DSPi Console.
I do have a MacBook Pro M4 Pro with a Thunderbolt 5 USB. Could it be that this is the issue?
Other than that DSPi works perfectly
BTW: What does the Buffer Pool "8 under" mean (see attachment)?

 

[bogdansrb]

I've been following this topic and I think it would work well with the CS42516 codec, since it has S/PDIF inputs. I'm thinking of building a DSP crossover with a Pico and the codec included, with 6 outputs that can be used on a stereo 3-way.
Are you planning on adding S/PDIF or I2S inputs apart from USB? And if so, can the DSPi be configured with the app and keep its filter and output settings so that the final product is standalone?

 

[Weeb Labs]

I've update now my MacOS to 15.7.4 and I have still the problem that Pico 2 disappears from the Finder after connecting with the DSPi Console.
I also tried to switch back to my Pico 2040 but it always showed up as the RP2350 in the Finder even after installing the FW for the Pico 2040. Hence the Pico couldn't connect at all to DSPi Console.
I do have a MacBook Pro M4 Pro with a Thunderbolt 5 USB. Could it be that this is the issue?
Other than that DSPi works perfectly
BTW: What does the Buffer Pool "8 under" mean (see attachment)?

The "8 under" value refers to buffer underruns on the USB-DMA buffer. These can indicate a problem (audio glitches) if they occur in large numbers but they are a normal occurrence when stopping/starting playback or switching between playback applications. Were you seeing them accumulate rapidly during audio playback, that would indicate a problem.

I've been following this topic and I think it would work well with the CS42516 codec, since it has S/PDIF inputs. I'm thinking of building a DSP crossover with a Pico and the codec included, with 6 outputs that can be used on a stereo 3-way.
Are you planning on adding S/PDIF or I2S inputs apart from USB? And if so, can the DSPi be configured with the app and keep its filter and output settings so that the final product is standalone?

Yes, SPDIF and I2S inputs are planned. Once DSPi is configured within the application and changes saved, they will persist without needing to be connected to a PC.

 

[kwas]

I haven't personally tested this but as the DSPi is a standard UAC1 device, it should be supported by any platform that implements USB audio.

OK, so here's an idea...
Any chance of somehow implementing IR receiver or a motorized pot for global volume with remote?

 

[Weeb Labs]

OK, so here's an idea...
Any chance of somehow implementing IR receiver or a motorized pot for global volume with remote?

Yes. Support for several control interfaces are planned. Among them are IR remote control, Bluetooth via phone application, web UI and volume potentiometer.

 

[Sonic-Wall]

No, the underuns just increased to 11 and then didn‘t increase any further.
I also noticed, that the maximum sampling frequency is limited to 96 kHz, correct?
Any plans, to store modified or imported filters under „Favorites“?

 

[Weeb Labs]

No, the underuns just increased to 11 and then didn‘t increase any further.
I also noticed, that the maximum sampling frequency is limited to 96 kHz, correct?
Any plans, to store modified or imported filters under „Favorites“?

That's good. The maximum recommended sample rate is 48KHz, as doubling it to 96KHz halves the available DSP cycles without an audible benefit.

I do have plans to implement user presets.

PSA: There is currently a bug in the v1.0.9 firmware for the RP2040 that increases RAM usage. It will be addressed in a hotfix within the hour.

 

[Weeb Labs]

Today has been spent squashing many relatively small bugs, optimising the bejeezus out of the RP2040 and refining the handling of different boards within DSPi Console. That is not to say there is no new functionality, of course.

Here is the summary:

• RP2040: Support has been added for four channel output (2xSPDIF)
• RP2040: Each channel now supports 10 PEQ slots (previously 10 per input and 2 per output)
• RP2040: Core 1 dual mode implemented; EQ Worker and PDM modes, as with the RP2350
• RP2040: Maximum per-channel delay is now 50ms (17 metres of time alignment)
• RP2040: Output pin reassignment no longer crashes the device
• RP2040/2350: Mute now applies correctly from the host
• RP2040/2350: Host volume adjustment range is now 0dB to -60dB, in line with industry standard (previously 0dB to -91dB)
• RP2040/2350: Disabling a single channel from a SPDIF pair no longer produces idle tones on that channel
• DSPi Console for macOS: Matrix Mixer now shows only the available four output channels plus PDM when an RP2040 is connected
• DSPi Console for macOS: Pin Assignment section in Settings now shows only the available two SPDIF outputs plus PDM when an RP2040 is connected

Links:

• DSPi Firmware v1.1.0
• DSPi Console v1.1.0 for macOS

Once I have designed the new channel peak metering implementation, then it will be time to port all of the current functionality over to the DSPi Console for Windows!

 

[mike_008]

Eight channels are the practical limit, so that would be four bidirectional channels

So in case someone would want to route 16 input/output channels from i2s to USB four Picos would be needed, right?
(maybe with some future sw version…)
Could these four Picos be synced in some way by HW clk from one pcb to the other to have USB streams not drifting away?

 

[capslock]

That raises a point I was wondering about. How is the master clock generated and in what amount of jitter does this result?

 

[Ktacos]

What kind of amp/dac setup would one need to take advantage of this for doing speaker xovers. I don't really know of many small amps with digital inputs. Would a few of those little spdif to analog out converters that go for $20-ish and under work?

 

[Weeb Labs]

That raises a point I was wondering about. How is the master clock generated and in what amount of jitter does this result?

At the moment, the master clock would be generated via the PIO divider. The amount of jitter depends upon a few factors. Minimizing it at the moment would entail using a system clock frequency that enables an integer PIO clock divider rather than a fractional one.

Another approach is to make use of I2S DACs with internal PLLs that do not require a master clock or an ASRC.

Ultimately, the custom DSPi board design will likely make use of an external clock source for the PIO, producing minimal output jitter for I2S and TDM8.

What kind of amp/dac setup would one need to take advantage of this for doing speaker xovers. I don't really know of many small amps with digital inputs. Would a few of those little spdif to analog out converters that go for $20-ish and under work?

One stereo DAC per SPDIF output is required. Yes, any cheap DAC will be suitable, provided its performance meets your requirements.

 

[V17]

I just want to say that this is cool as shit. Years ago I tried convincing a standard Raspberry Pi to simultaneously act as a standard USB audio soundcard and a on a different physical port as a USB host, to process incoming audio and send it to a real soundcard. Afaik the hardware theoretically supports this and the drivers exist, but I wasn't able to actually make it work.

I understand that using some of the channels as input instead of output is theoretically possible? Is the feature planned? Sorry, I haven't read the whole 18 pages.

And does the whole unit create any significant latency (when only using IIR filters, not any effects that produce latency by definition)?

edit: Total latency about 10 ms, I see. So good enough for any home use.

 

[nullpointerninja]

Slightly off topic but would it be technically possible to have multiple I2S inputs like from those HDMI to I2S boards so we can mix multi channel audio? Might be too much to handle for the Pico but I imagine this would be a poor man’s audio processor for surround applications (bass management, channel routing/delays, etc).

 

[TurtlePaul]

Slightly off topic but would it be technically possible to have multiple I2S inputs like from those HDMI to I2S boards so we can mix multi channel audio? Might be too much to handle for the Pico but I imagine this would be a poor man’s audio processor for surround applications (bass management, channel routing/delays, etc).

The problem becomes that upstream devices deliver their clock to the downstream device and you would need an asynchronous sample rate converter to reclock each input. The Pico does not have audio ASRCs built in and it is too slow to do multiple inputs in software.