• Welcome to ASR. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

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

A little status update. After stepping through all prior commits and releases, I have determined that the root cause of the dropouts actually has nothing to do with system clock. It is caused by retention of old, incompatible parameters in the persistent flash memory being carried across firmware versions. This is something I had attempted to guard against with flash versioning but it appears my guards were inadequate.

Once the flash is cleared, all issues seem to disappear. I will be implementing automated clearing as part of each update after sufficient testing confirms my diagnosis. Clearing old parameters also appears to have eliminated the need for a feedback servo, as buffer fill now tracks 50% unaided. Very odd failure mechanism.
 
I barely understand what you just said, but it sounds so poetic to me that I'm starting to think you're a surrealist, or at least well on your way. ;)

In any case, this dropout story is a case with multiple twists and turns!
 
When I installed the most recent version of REW, it also uninstalled the old version automatically.
Would this be a good feature for the updated console installs?
 
Auto-sensing switchers also exist.

Personally I do not envision DSPi as a general use preamp even for volume control much less source switching for all kinds of inputs.

For me, it handles DSP filter processing, two input channels at a time.

The mixing ability for concurrent sources I can see, a gamer's console integrated with PC for Zoom calls and the like...
I envision DSPi to be quite versatile and do whatever the user needs.
Personally I see it as a preamp with several inputs (maybe even with multi-PCM support) and eight outputs, with a physical volume knob (with variable loudness, nomnom!) and input switch button or maybe knob and maybe even a small screen, and then of course the whole DSP thing with PEQ, crossovers, delays and mid/side-processing.
I*m quite excited for it really because I want to upgrade from my MiniDSP 2x4HD, and seeing that I love these kinds of DIY projects that can be done really cheap while still performing as SOTA this will suit me just perfectly!
That's a finished box that can include this board for DSP.

If handling multi-channel, then multiple instances of the DSPi are needed.

But all those functions are separate products, and will have to be priced like miniDSP's or likely more until volume ramps up.

The DSPi board itself is a DIY component, and should not try to be all things to all users.

IMHO
I understand scope creep all too well and agree that no one device, especially DIY, is going to be able to do everything and do it well. I struggle understanding how to utilize the DSPi effectively if it’s not “the” DSP digital pre-amp though. Specifically in regards to volume and crossover. Maybe it’s a bit different if the use is as DSP for a powered speaker. Without using the DSPi in this way, how could it be used effectively as a crossover for a 2.1 if it wasn’t acting as the master volume control and input selector? Perhaps it is the capability gab between USB and toslink input that is throwing me, because toslink is typically full amplitude, which would require downstream DACs to have some other way to synchronize volume control.
 
Hello, how should I use the preamp volume correctly? I use 20 peq bands for one channel, so I have to combine 10 peq for input and 10 peq for output for one channel, I have a positive + 12db low shelf for bass emphasis, I lower the preamp to -10db, but after restarting or switching presets it always resets and the sound and indicator show clipping, even -10dB gain on input and output does not help. I use firmware DSPi-RP2350-v1.1.2b-hotfix2 and DSPi Console v1.1.2b Win x64. Thank you
 
Nothing more impressive that someone who actually implements a fantasy project I mull over in my head but do nothing about, and implements it far and away better than I think I would/could. :D Massive Kudos Weeb Labs!
 
I struggle understanding how to utilize the DSPi effectively if it’s not “the” DSP digital pre-amp though. Specifically in regards to volume and crossover.
I am a noob, so please ELI5 if I am wrong. I have never imagined these two functiins have ever has anything to do with each other.

Active crossovers always put the frequency splitting before the power amp, regardless if that is attached to the speaker enclosure or not. Many such power amps have no gain / volume control, or if they do are intended to "set and forget".

The functioning of the active crossover should be consistent if the whole-system volume control is prior, i.e. a separate preamp stage (perhaps also with source switching, phono input etc) precedes the DSP convolver in the signal chain.

> Maybe it’s a bit different if the use is as DSP for a powered speaker.

And of course with multiple such convolvers, each feeding separate (sets of) channels, that separate preamp MUST come prior.

With ad-hoc controls like variable loudness compensation (must be integrated with volume control), tone controls / PEQ per album or per track

IF you want to implement those using DSPi, then that must involve one upstream of the others, unless one day there is some sort of comms protocol between them.


> Without using the DSPi in this way, how could it be used effectively as a crossover for a 2.1 if it wasn’t acting as the master volume control

So, again, nothing to do with the crossover function, but if you only need one DSPi you certainly COULD use it for that

> and input selector?

That would be interesting, but for multiple analog sources including phono I'd do that old-school, and then just one stereo ADC into DSPi

USB makes a great SQ audio transport, whether before or after processing, volume controls etc.
 
And of course with multiple such convolvers, each feeding separate (sets of) channels, that separate preamp MUST come prior.

So if if the preamp must come prior to the DSPi, it must therefore be a digital preamp. Correct me if I am wrong, but a digital preamp is just another term for a DSP.
 
So if if the preamp must come prior to the DSPi, it must therefore be a digital preamp.
Wut? why?

ADCs are a thing.

Also "digital preamps" don't necessarily do "DSP functions" that involve EQ, timing delays, phase correction, compression, effects etc.

to me just because (in an active system) all these things happen before power amplifier

does not mean they are essential functionality of "a preamp"

Those essential functions are gain matching and volume control on the one hand, and source selection on the other

"Extras" like balance, tone controls, loudness compensation just like those two essential ones can be implemented in analog maybe just as well or better.

Yes so many DSP units put EVERYTHING together, I agree in many cases that is preferable.

I prefer modularity, in fact my use case requires it.


 
Like a DAC uses DSP filters, but that does not make it "a DSP" if it does no PEQ, speaker or room compensation, crossovers, etc

Look at Schiit Eitr 2 or Mimir Forkbeard feature list, yes FB turns them into a digital preamp, yes it does all those things using DSP

However no one would call them "a DSP engine" in the sense used for DSPi or CamillaDSP or on a PC Equalizer APO, Roon, JRiver, HQPlayer
 
Like i said in the other thread :

"Modularity you will have!

The question of volume management at the DSPi level or not has already been mentioned in the main thread a few weeks ago. In any case, the choice will be left to the end user. Troy is working incredibly hard to offer us a whole host of flexible options, to make the DSPi, as he says, "a Swiss Army knife."

But before considering advanced uses, we just need to wait a little while for development to progress further.

Be patient.;)"
 
Not sure if this is the correct thread of the two....... :p but I have knocked up an incomplete schematic of the kind of system I would like to build. I hope it is of use to someone.

Ideally one firmware version could be used for all three Pico 2 and if you only want stereo, then just miss off the RHS of the schematic and take the I2S output from the first Pico board. I assume that by dividing function between multiple Pico 2, it would free-up processing power to be used in more filters or resolution(?).

Fascinating project however it turns out. @Weeb Labs - thank you and please take care of yourself! ;)
 

Attachments

Not sure if this is the correct thread of the two....... :p but I have knocked up an incomplete schematic of the kind of system I would like to build. I hope it is of use to someone.

Ideally one firmware version could be used for all three Pico 2 and if you only want stereo, then just miss off the RHS of the schematic and take the I2S output from the first Pico board. I assume that by dividing function between multiple Pico 2, it would free-up processing power to be used in more filters or resolution(?).

Fascinating project however it turns out. @Weeb Labs - thank you and please take care of yourself! ;)
Great job! And an interesting proposal!
 
interesting proposal!
Haha, thanks :D

I was mainly thinking about the most complicated system you could reasonably expect (4-way stereo + 3-4 subs) and working backwards to see if it might be possible to make with multiples of the same DSPi hardware/firmware. It looks feasible, but asking Troy to write firmware for it depends on demand and resources - I should bribe him with Ko-Fi soon! Unfortunately I'm mid house-move so most of my stuff is in boxes, otherwise I'd be checking the current version out now. So far as custom PCBs go, the hardware is stunningly cheap but I don't have much experience in routing reasonably fast clock traces on PCBs - I'm just a hobbyist! o_O
 
Haha, thanks :D

I was mainly thinking about the most complicated system you could reasonably expect (4-way stereo + 3-4 subs) and working backwards to see if it might be possible to make with multiples of the same DSPi hardware/firmware. It looks feasible, but asking Troy to write firmware for it depends on demand and resources - I should bribe him with Ko-Fi soon! Unfortunately I'm mid house-move so most of my stuff is in boxes, otherwise I'd be checking the current version out now. So far as custom PCBs go, the hardware is stunningly cheap but I don't have much experience in routing reasonably fast clock traces on PCBs - I'm just a hobbyist! o_O
I'm working on something similar, but with a single Pico. For now I'm almost finishing an AK4619 version (4 channel ADC + 4 channel DAC). But I'll be doing a 6 or 8 channel out version with separate ADC and DAC.
 
I believe that I can safely declare the dropout issue resolved at this point.

1774903443265.png


I have set up a Mac mini with a fresh installation for testing purposes. It has now been playing continuously for more than 12 hours, without an incident. The bug fix will be committed and a hot fix pushed shortly. :)
 
I am curious as to who has been using DSPi on a USB hub rather than direct connection.
 
I am curious as to who has been using DSPi on a USB hub rather than direct connection.

I'm using it on a Mac Studio with those fancy hubs that sits on the bottom and on my Macbook I use it with those Ugreen hubs that has SD/Ethernet/HDMI without problems.
 
I am curious as to who has been using DSPi on a USB hub rather than direct connection.
I have. It seems to work. It was just a matter of convenience because the computer isn't easily accessible and the hub is on the desktop. I've also used it with a USB switch with several Raspberry Pis and a mini-PC connected to the same amp.
 
So, several bugs have been eliminated and robustness has been improved but throughout my debugging, I have learned that despite a few aggravating factors (flash guards, buffers) the firmware itself was not chiefly responsible for the dropouts. Rather, it is the fact that the RP2350/2040 tends not to play nicely with USB hubs. This fact is apparently well known but I had no knowledge of it.

Since I began work on this project in January, I have been using the same inexpensive USB 3.0 hub for all testing. I had previously noticed some odd behavior and occasional artifacts but simply put this down to my Mac, which was typically under load. As it turns out, the dropouts had always been occurring but went unnoticed due to their relatively low incidence. Now that DSPi is in constant use, they're more obvious.

The solution is simply to connect the Pico directly to a USB root port and not to a hub. In conjunction with the upcoming flash and buffer overhaul, this completely eliminates all dropouts.

Additional observations that I have made are that the Pico is quite sensitive to marginal USB cables and ports. This makes sense, as there is no onboard VBUS filtering other than a pair of small decoupling capacitors. If the DC input is not stable, the board has no suppression for this.

In summary, avoid USB hubs if possible and use USB cables of reasonable length and quality. Some hubs work perfectly but others cause problems. I will be pushing the hotfix after a few more hours of soak test. :)
 
Last edited:
Back
Top Bottom