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

[Kingsnake]

Can you really recover the clock from SPDIF on the Pico? This would require a digital PLL, wouldn't it?

Why would one want to mix SPDIF in and USB, i.e. what is the use case for that? How would you go about it? Lock to SPDIF and use the recovered clock as the master for the USB input?

A single DSP chain handles whichever input is selected:
USB from PC
SPDIF from TV
SPDIF from CD player / console
RCA from turntable

All go through the same processing:
Room EQ, Subwoofer crossover / bass management delay / phase alignment, volume control, all while keeping one consistent DSP profile.

That’s very typical for DSP DACs and miniDSP devices the complexity is mainly clock handling between inputs, not the DSP concept itself.

 

[john61ct]

So maybe these multiple source-select and conversion functions should be outsourced to one or more front-end box configurations

which passes the channels to the DSP-function box that only needs to support one selected medium, e.g. S/PDIF coax.

I've no idea how the need for a Master clock fits into this when building clusters of Pico's to handle lots of channels, apparently Dante is good for that?

 

[somebodyelse]

I've no idea how the need for a Master clock fits into this when building clusters of Pico's to handle lots of channels, apparently Dante is good for that?

AFAIK there's no open Dante implementation, and it would need a wired network connection anyway - it relies on PTP for time sync. It really isn't applicable in this scenario.

 

[FraPia-62]

AFAIK there's no open Dante implementation, and it would need a wired network connection anyway - it relies on PTP for time sync. It really isn't applicable in this scenario.

AES67/RAVENNA is open source and could be used also in a Dante network configured in AES67 mode. I would have applications for that, however mainly in the pro audio domain, less at home.

 

[Weeb Labs]

I expect to push a new release later this evening, which will include 24-bit USB input and 24-bit SPDIF output.

Switched SPDIF input will be next.

 

[somebodyelse]

AES67/RAVENNA is open source and could be used also in a Dante network configured in AES67 mode. I would have applications for that, however mainly in the pro audio domain, less at home.

Something like https://github.com/SavilleBelcher/AES67Teensy perhaps? That's on a board that's rather more powerful than the Pico though, and has wired networking built in.

 

[FraPia-62]

Something like https://github.com/SavilleBelcher/AES67Teensy perhaps? That's on a board that's rather more powerful than the Pico though, and has wired networking built in.

Yes, but I don't know if it can be ported to the Pico. I cannot write code, thus I don't really know.
Here are some other AES67 resources that can be useful:

GitHub - Mo-way/awesome-aoip: A curated list of awesome Audio over IP and AES67 tools and resources

A curated list of awesome Audio over IP and AES67 tools and resources - Mo-way/awesome-aoip

github.com

If the Pico runs PipeWire, AES67 support could be provided via pipewire-aes67.

 

[TurtlePaul]

If you are after AES67, just start with another approach. The Pico doesn't have a network interface. You can see in the Github where Weeb is counting the kb of RAM available and the CPU cycles. AES67 needs a full network stack, not something you are going to put on a microcontroller. There are already full-sized RPi AES67 implementations, I would recommend starting there instead.

 

[Weeb Labs]

AES67 is not a realistic possibility for the RP2040/RP2350, unfortunately. UDP audio is certainly feasible but nothing with guaranteed latency.

 

[somebodyelse]

If the Pico runs PipeWire, AES67 support could be provided via pipewire-aes67.

PipeWire needs a whole other class of board - look for something that runs linux and has a wired network connection. There are some inexpensive ones that would probably fit the bill, but we're getting way off topic.

 

[Weeb Labs]

DSPi Firmware v1.1.1 is now available with full support for 24-bit input and 24-bit output via USB and SPDIF!

As always, I highly encourage users to report any bugs that they encounter, large or small.

I am now working on SPDIF input. This is by no means the final UI but it is in a testable state.

 

[m_g_s_g]

DSPi Firmware v1.1.1 is now available with full support for 24-bit input and output via USB and SPDIF!

I understand here USB 24-bit input and SPDIF 24-bit output, right? That's good news.

Or do you really mean USB output, either back through the same USB port to the originating host as an audio endpoint ("mic device"), or bit-banging another USB port using Tinyusb host features?

 

[Weeb Labs]

I understand here USB 24-bit input and SPDIF 24-bit output, right? That's good news.

Or do you really mean USB output, either back through the same USB port to the originating host as an audio endpoint ("mic device"), or bit-banging another USB port using Tinyusb host features?

24-bit USB input and 24-bit SPDIF output.

 

[DamianD]

Great addition! Please don't forget about Linkwitz Transform and 1st / 2nd order All-pass filters. Small addition, big IIR functionality.

 

[Sonic-Wall]

Thanks for the documentation!
I guess, the I2S signal from the pico is currently 16 bit but my converter requires 24 bit and probably also MCLK.
However Weeb is already working on the 24 bit SPDIF and hopefully soon on 24 bit I2S

@giubeppe Now that we have a 24 bit SPDIF output could you please add your I2S outputs again?

 

[Kingsnake]

Am I right in thinking it’s generally better to use an inexpensive, well-measured DAC in an enclosure via Toslink rather than a cheap I2S DAC board?
The I2S boards that have solid, published measurements tend to be relatively expensive compared with what you can get from brands like SMSL. Meanwhile, many cheaper Chinese I2S boards advertise high-end DAC chips but provide little or no real performance data to back up their claims.

 

[somebodyelse]

Or do you really mean USB output, either back through the same USB port to the originating host as an audio endpoint ("mic device"), or bit-banging another USB port using Tinyusb host features?

TinyUSB host isn't (yet) capable of doing USB Audio. From https://docs.tinyusb.org/en/latest/ at time of posting:

Host Stack​

• Communication Device Class: CDC-ACM
• Vendor serial over USB: FTDI, CP210x, CH34x, PL2303
• Human Interface Device (HID): Keyboard, Mouse, Generic
• Mass Storage Class (MSC)
• Musical Instrument Digital Interface (MIDI)
• Hub with multiple-level support

Similar to the Device Stack, if you have a special requirement, <span>usbh_app_driver_get_cb()</span> can be used to write your own class driver without modifying the stack.

Someone might write the necessary audio class driver at some point.

 

[Wesseling Audio Lab]

As always, I highly encourage users to report any bugs that they encounter, large or small.

I'm now running 1.1.1 firmware and 1.1.0 console
When I enable any SPDIF R "only" in the mixer it isn't displayed in the pin assignment screen, but the output is actually on. When SPDIF L is enabled pin assignment is displayed
Previous firmware R only is displayed

 

[TurtlePaul]

1.11 is working well for me. Awesome that a month and a lot of determination from a single developer has made a DSP implementation that surpasses what many audio hardware brands have been able to produce. Weeb, thank you so much!

 

[giubeppe]

@giubeppe Now that we have a 24 bit SPDIF output could you please add your I2S outputs again?

Yes, I’ll pull latest changes and see how to integrate them for I2S 24bit output.