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

[john61ct]

Found this on Ali

Thanks, but like I said, this gets expensive doing it pairwise when the goal is ADAT integration, 8x channels in each direction

to continue here

DIY with DB-25 ? Rack panel, not snakes

I've been looking for high SQ / low price per analog port secondhand interfaces and ADAT A/D converter "breakout boxes" for DSP use. I found some units that use DB25 TASCAM pinout connectors rather than hosting the ports onboard, very nice feature sets lotsa ports, going for cheap And then...

www.audiosciencereview.com

 

[john61ct]

ADAT in-out
...
I wonder if you can explain more about the concept of multi-DSPi?

Just a noobish fellow fan here, none of this reflects the dev's intentions

My "Modularised DSP ™ " dream is mix and matching distributed processing, both at stereo input for the overall system,

or downstream after solitting just before the amplification.

Some channels have a very low need for processing power, say just doing a loudness contoured Volume Level control, or a simple crossover + delay at higher frequencies, or "anechoic" per-driver correction.

Maybe one DSPi node can handle 8ch!

Or as things get heavier, one node just services a pair.

In some cases (FIR) RPi SBC horsepower is required.

in others, DSPi might just be an inexpensive DDC, even ADAT-based format converter, no actual DSP done at that node.

After the streamer/source output stage, USB in and out hets complicated (host capabilities vs OTG/gadget mode restrictions.

Back and forth to analog is sub optimal, really any ADC is for the source switching / preamp stage, and DAC ports should be "as needed" at the final amp input only

IMO stick to S/PDIF, AES and ADAT for the whole "line level" signal chain

 

[Weeb Labs]

____Amazing____ v1.1.5 is already a dream come true enabler of so many awesome use-cases - with ADAT in-out . Now with new roadmap I again see several crazy cool features to be excited about, including Room correction (hopefully with manual control and access to a shared pool of extra PEQs).


I wonder if you can explain more about the concept of multi-DSPi? :

• Support for multi-DSPi configurations with epoch sync signaling for phase-locked output across any number of slaved DSPi devices

Is this intended to run multiple DSPi units over USB input like aggregated audio device in MacOS? I am very interested to have 16ch-out @ 24bits, and that is why using a pro audio interface with ADAT outputs towards DSPi seems like the only option at the moment (given limitations of 16bit-8channels over USB for DSPi).

Also looking forward for official hardware - it probably needs to be modular or have many variants to suppport various features like optical input (maybe even AES3 input?) and digital outputs as well as DACs with sufficient Voltage drive (over 2V? and hopefully SINAD of 100+dB).

I didn't mention this in the announcement but we will almost certainly be supporting 16-channel (logical) output for sources such as USB, SPDIF and certain I2S configurations.

Regarding mult-DSPi, the idea is that a single device will function as the clock master and will route audio to any number of slave devices without affecting the total system latency. All devices will be epoch synchronized and perform DSP in parallel, with sample-aligned output. This might be useful for large distributed configurations, many-way speakers or Atmos-like installations. Input channels at the master device would still be 8, of course.

 

[john61ct]

Very exciting stuff!

we will almost certainly be supporting 16-channel (logical) output
...
Input channels at the master device would still be 8, of course.

Plenty for my use cases, but blue sky...

If more than 8ch input is needed, could the idea of "only one Master node" be for the clocking domain?

While more than one node can accept input Signal channels?

 

[90sNintendoKid]

I want to use multi DSPis to upmix 7.1 to height channels and make a Scatmos system.

 

[somebodyelse]

Regarding mult-DSPi, the idea is that a single device will function as the clock master and will route audio to any number of slave devices without affecting the total system latency. All devices will be epoch synchronized and perform DSP in parallel, with sample-aligned output. This might be useful for large distributed configurations, many-way speakers or Atmos-like installations. Input channels at the master device would still be 8, of course.

Expanding on the use cases from @SDX-LV and @john61ct, clock-synchronised DSPi modules that accept 8 channels each via their respective USB inputs could be used in linux to create a device with more than 8 output channels - I don't know what the limiting factor would be for the maximum channel count. Linux has a couple of mechanisms to make virtual multichannel devices from multiple interfaces, similar to MacOS. In asoundrc you can create a pcm.multi device - these need clock sync to stop them drifting apart. In PipeWire you can use Combine Stream - this will use ASRC to keep sync by default, but if you have clock sync you can save some CPU by setting matching clock.name for the synchronised devices which will skip the ASRC. I think MacOS does something similar with ASRC but don't know whether it has something to avoid it where clock sync is available.

I'd guess the likely reasons for needing the high channel count would be software-based Atmos playback using Cavern or similar, or FIR-based active crossovers.

 

[Wolf11Man]

It might be helpful to update the hardware sources from time to time. It would also be good to list alternative ordering options, as there can be different restrictions depending on location—for example, links to EU retailers, AliExpress, or eBay. I want to make sure I get the right hardware without any nasty surprises.

You are doing an incredible job; even the basic features you’ve implemented go beyond what one would expect from an open-source project like this. I was already completely satisfied with the standard DSP functions, including the analog input and maybe the simple digital one.

Thanks again!

 

[staticV3]

I'd like to design a carrier board for the Pico with Optical input and B&O Powerlink output to my Amp, including ideally the 5V trigger functionality for Amp Auto On/Off.

Does DSPi currently include any logic for controlling external Trigger circuitry?

I know there's the DAC Hardware Mute which I'd still like to use for the external DAC.
What I'm looking for is something that goes low after x minutes since the last input signal (user defined) and goes high again once the signal resumes.

 

[Weeb Labs]

I'd like to design a carrier board for the Pico with Optical input and B&O Powerlink output to my Amp, including ideally the 5V trigger functionality for Amp Auto On/Off.

Does DSPi currently include any logic for controlling external Trigger circuitry?

I know there's the DAC Hardware Mute which I'd still like to use for the external DAC.
What I'm looking for is something that goes low after x minutes (user defined) since the last input signal and goes high again once the signal resumes.

This does not currently exist but is a great idea! I will fold it into this weekend's initial v1.1.6 beta as a new Timers component within Control Surfaces.

 

[staticV3]

This does not currently exist but is a great idea! I will fold it into this weekend's initial v1.1.6 beta as a new Timers component within Control Surfaces.

Awesome! Thank you so much!

 

[kboe]

I didn't mention this in the announcement but we will almost certainly be supporting 16-channel (logical) output for sources such as USB, SPDIF and certain I2S configurations.

Regarding mult-DSPi, the idea is that a single device will function as the clock master and will route audio to any number of slave devices without affecting the total system latency. All devices will be epoch synchronized and perform DSP in parallel, with sample-aligned output. This might be useful for large distributed configurations, many-way speakers or Atmos-like installations. Input channels at the master device would still be 8, of course.

This looks like heaven to me.
I will be trying a center channel for my stereo setup soon. If this turns out to my liking I will sooner or later face the challenge to process 11 channels.
3 * 3-way mains and center plus 2 subs.
Input will be stereo from 3 sources via TOSLink and USB from my PC.
If I understand your post correctly this will be feasible with one DSPi only?
How will those 16 channels be put out?
What would be a solution for a good DAC? I need true balanced ground-free outputs due to long distances and bad experience with RCA connections in the past.
In the moment the mains are running on Hypex FAs. Their SW is far from comfortable and I have issues every now and then. It seems that the stereo center is moving sideways sometimes. If I measure, both channels play at identical SPL. So my conclusion is they are losing synchronicity being daisy chained via AES.
A cold restart cures the issue most of the times.
So 1 central DSP should be more comfortable to set up and has hopefully no timing issues.

 

[90sNintendoKid]

This does not currently exist but is a great idea! I will fold it into this weekend's initial v1.1.6 beta as a new Timers component within Control Surfaces.

I like this, in my opinion this is the future of software development.

 

[Mike123]

I'm want building a DSPi-based amplifier with an active crossover and room correction to drive three-way speakers. I'll be using four MA12070P amplifiers. So I'm studying the DSPi in detail. I really liked the room correction. I compared the DSPi with the EqualizerAPO. The results were virtually identical. Considering the cost and processor power, the author's work is excellent.


However, I ran into a small issue when testing the crossover bandpass filters. Artifacts appeared for the woofer at 36 and 48 dB per octave attenuation at frequencies up to 1 kHz. At 12 and 24 dB per octave attenuation, there were no such artifacts. I'm not sure how necessary such hi-order filters are . But if they're, they should work.

 

[TurtlePaul]

Weeb, I see the menu for Control Surfaces to control either Master Volume or User Volume with either a pot or a rotary encoder. Do I wire the fixed ends of the potentiometer to 0V and 5V and then let the leg sweep across the voltage? I assume that a linear taper 10k or 25k ohm pot will do?

 

[jrosser]

Weeb, I see the menu for Control Surfaces to control either Master Volume or User Volume with either a pot or a rotary encoder. Do I wire the fixed ends of the potentiometer to 0V and 5V and then let the leg sweep across the voltage? I assume that a linear taper 10k or 25k ohm pot will do?

The ADC voltage reference is 3.3v, so that is the voltage that will result in the maximum possible ADC reading. The original RP2040 is not 5v tolerant on its I/O, but the RP2350 is, unless the chip is powered off or booting.

So, for a potentiometer input, you should use 0V and 3V3 on the ends of the pot. Avoid any 5V inputs unless you can satisfy the RP2350 requirements for it being 5v tolerant.

 

[anotherhobby]

I see a really interesting intersection between this DSPi project and a rotary encoder remote control project that I'm working on. Two weeks ago I started building a desktop remote control for my Denon in my office using an ESP32 based M5Dial as my hardware. The thread is here: deloop - an open source M5Dial remote and volume knob. It controls power, volume, mute, input, DSP presets, and in some cases media controls, all thru a small touch screen and rotary encoder. Functionality is heavily inspired by the direct controls and dispaly I'd gotten used to with my miniDSP Flex.

From personal experience, I'm keenly aware that there are many DSP devices out there that don't have a good desktop control interface, so I started extending deloop to all the ones that I own or have ran. Currently it supports Denon, minidsp-rs, CamillaDSP, wiim, and Home Assistant media players. I don't think anybody is actually using this thing yet by me, but I'm having fun integrating the devices I own, and I'm really happy with it for daily use. In the last week I put a lot of effort into responsiveness, and I should really get around to recording a new demo video. That said, it's also only battle tested in an environment of one, so I'll be curious to see how it does in the wild.

I was reading thru this thread this morning, and here we have another sweet DSP device in need of a control interface. I dropped the DSPi repo into my project and asked Claude to do the digging to see if support would be easy to extend, and it came back with "Short answer: yes, and it's arguably the cleanest fit of any backend so far." Oh Claude, always so enthusiastic and confident. The reason for it's enthusiasm is that every other back end gets device side updates by polling over the network, whereas with DSPi we could connect direct and use UART, get push events, and eliminate the network between deloop and the DSP device, would would also eliminate any network latency there is today. This got Claude all tingly.

Looking thru the source for the DSPi control plane, the current deloop controls all map well as is. DSPi also has several additional control options that would probably useful to add in the menu, or even promoted to main screen as a one-touch tap control like the DSP presets are. It woudln't take me too much effort to add support. I'd just need to buy the Pico so I could do actual live hardware/behavior testing, and it seems like a fun thing to mess with if it's something people would use.

Thoughts? Interest?

 

[Tell]

I see a really interesting intersection between this DSPi project and a rotary encoder remote control project that I'm working on. Two weeks ago I started building a desktop remote control for my Denon in my office using an ESP32 based M5Dial as my hardware. The thread is here: deloop - an open source M5Dial remote and volume knob. It controls power, volume, mute, input, DSP presets, and in some cases media controls, all thru a small touch screen and rotary encoder. Functionality is heavily inspired by the direct controls and dispaly I'd gotten used to with my miniDSP Flex.

From personal experience, I'm keenly aware that there are many DSP devices out there that don't have a good desktop control interface, so I started extending deloop to all the ones that I own or have ran. Currently it supports Denon, minidsp-rs, CamillaDSP, wiim, and Home Assistant media players. I don't think anybody is actually using this thing yet by me, but I'm having fun integrating the devices I own, and I'm really happy with it for daily use. In the last week I put a lot of effort into responsiveness, and I should really get around to recording a new demo video. That said, it's also only battle tested in an environment of one, so I'll be curious to see how it does in the wild.

I was reading thru this thread this morning, and here we have another sweet DSP device in need of a control interface. I dropped the DSPi repo into my project and asked Claude to do the digging to see if support would be easy to extend, and it came back with "Short answer: yes, and it's arguably the cleanest fit of any backend so far." Oh Claude, always so enthusiastic and confident. The reason for it's enthusiasm is that every other back end gets device side updates by polling over the network, whereas with DSPi we could connect direct and use UART, get push events, and eliminate the network between deloop and the DSP device, would would also eliminate any network latency there is today. This got Claude all tingly.

Looking thru the source for the DSPi control plane, the current deloop controls all map well as is. DSPi also has several additional control options that would probably useful to add in the menu, or even promoted to main screen as a one-touch tap control like the DSP presets are. It woudln't take me too much effort to add support. I'd just need to buy the Pico so I could do actual live hardware/behavior testing, and it seems like a fun thing to mess with if it's something people would use.

Thoughts? Interest?

Don't know if I'd use it, but I really like the idea and other people probably are too, so why not? ^^

 

[john61ct]

Thoughts? Interest?

Very high interest here.

Besides clean SQ my two deal-breakers sine qua non requirements for ad-hoc user control of volume are

1. close at hand in my varying positions at MLP

2. an instant Mute, and

3. a fine implementation of automatically-scale-with-SPL Loudness Contour, ideally tweakable.

(4.) Big Knob on top, hefty weight, with nice tactile feedback whether smooth or with indents is a "would be Very nice".

 

[anotherhobby]

Don't know if I'd use it, but I really like the idea and other people probably are too, so why not? ^^

I ended up tossing the Pico in my amazon cart and will be making a run at it just for fun. Like you said... why not. I'm mostly curious which features from DSPi people would want one-touch on the main screen, or have included in menus for quick access.

Very high interest here.

Besides clean SQ my two deal-breakers sine qua non requirements for ad-hoc user control of volume are

1. close at hand in my varying positions at MLP

2. an instant Mute, and

3. a fine implementation of automatically-scale-with-SPL Loudness Contour, ideally tweakable.

(4.) Big Knob on top, hefty weight, with nice tactile feedback whether smooth or with indents is a "would be Very nice".

I would love a high-end M5Dial type product. Bigger screen, bigger knob, weighty and smooth high end feel, fully programmable esp32 still, and yeah, tactile feedback would be icing. Oof that would be nice, and I'd gladly pay more for it (within reason) if somebody finds or creates such a thing. The M5Dial is not going to satisfy anybody who requires a high-end feel, but it also doesn't feel super cheap once mounted.

 

[Fred H]

if it's something people would use

I would want it to be wireless, please. Otherwise, it looks great. (I turned down the miniDSP rotary for that reason.) I'm a probably-next-year user, so not immediately important.