• 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

@Weeb Labs would it be possible to have multiple instances of the Pico on the same Mac machine (i.e. one for head amp and another for active speakers)?
 
Just wondering, is Linkwitz Transform possible in the EQ functions
Yes. A Linkwitz transform is a biquad filter just like the other EQ filters, so it should just require a small addition to the firmware to calculate the coefficients plus whatever changes are needed for the console application.

Just in case @Weeb Labs finds it helpful, here are the formulae (discretized using the bilinear transform):
lt_formulae_1.png

lt_formulae_2.png


A analogous transform for 2nd-order lowpass filters requires only a small change to Kz and Kp:
lp_xfrm_k.png
 
Linkwitz transform
I think in the days of room correction, it is a rather pointless thing. What it tries to do is vastly overpowered by whatever the room does. So fixing the room response, and using that to cleanly extend the bass, is way more effective and yields much better results.
 
I'll gladly donate 20 again in the future. So little money for what you are developing! Many Thanks!:)

This ride is a thrill! I purchased 4 Pico's right of the bat with ideas for 4 systems.

Just wondering, is Linkwitz Transform possible in the EQ functions, even though it can be accomplished with shelf and peaking? - so probably not that necessary

Also, is a volume dependent variable low frequency roll off rate and point possible. ie, a sealed sub is EQ'd to reach 20hz at low volume but can be set to increase continuously with increase in volume at a selectable rate and desired slope.

Just ideas but can certainly go without them. Thanks Again!
I greatly appreciate your contribution. :)

If purchasing Picos for use with the firmware, I would highly recommend Pico 2s (or anything with an RP2350), as the performance uplift is immense for audio.

I will add the Linkwitz Transform as a feature request and implement it shortly. It's very straightforward to add as a filter type.

This sounds like Dynamic Range Compensation, with a level dependent response. Similar in principle to loudness compensated volume control but with additional parameters. This is absolutely something that can be implemented and it would be useful not only for subwoofers but for small drivers at low listening levels.


@Weeb Labs would it be possible to have multiple instances of the Pico on the same Mac machine (i.e. one for head amp and another for active speakers)?
Yes, this is entirely possible and will become emergent functionality once I have implemented device selection in DSPi Console, unique PIDs for both RPs and unique serial computation from flash ID.

Please bear in mind that 8-channel output (4xSPDIF) will soon be added, so you might find that a second board isn't needed after all!
 
Last edited:
fixing the room response, and using that to cleanly extend the bass, is way more effective and yields much better results.
Its utility goes far beyond just extending bass response (and that doesn't preclude the use of room EQ anyway...). I've found it quite useful for crossovers as one often has a 2nd-order highpass response that would ideally be a different Q or corner frequency (either higher or lower). A Linkwitz transform accomplishes exactly that. It can even be applied to lowpass responses (see above) and to higher-order systems that can be represented as cascaded 2nd-order sections.
 
Yes, this is entirely possible and will become emergent functionality once I have implemented device selection in DSPi Console and randomized PID identifier ranges for the boards.

Please bear in mind that 8-channel output (4xSPDIF) will soon be added, so you might find that a second board isn't needed after all!
Awesome!

Can't wait to try it!

Sent you a Ko-fi.
 
@Weeb Labs would it be possible to have multiple instances of the Pico on the same Mac machine (i.e. one for head amp and another for active speakers)?

You can use two USB outputs from your PC to the same DAC/headphone amp, with channel/source switching on the DAC:

USB output 1 → DAC: drives headphones directly.
USB output 2 → DSPi → TOSLINK → DAC RCA out to speaker amp → DSPi sub RCA → subwoofer.
On the DAC, you switch the input between USB 1 (headphones) and TOSLINK (speakers + sub) as needed. This lets you keep one DAC but choose between headphone-only or full system output.

You will need to also choose on your PC your desired sound device to use. DSPI usb or USB dac.
 
Thanks! :)

A small update before I get some sleep: I have successfully refactored the pico_audio_spdif library (with some help from robo intern), creating a new fork "creatively" named pico_audio_spdif_multi. This fork includes full support for instantiation and enables the creation of as many SPDIF outputs as the hardware can support (theoretically up to 12). Conveniently, all BMCs running on a given PIO block are phase and latency locked as they are driven by exactly the same divider clock.

For the moment, I have simply routed the subwoofer output to a second SPDIF on pin 22 and successfully tested simultaneous output. We now have up to eight functional digital output channels.

I'll commit this tomorrow, once I have had time to investigate edge cases. If everything is satisfactory, then a matrix mixer (2 in, 8 out) is our next stop.
hiya ive been reading through and just wanted to clarify as this is a little bit harder to follow for me . at the moment your adding more physical spliff outputs so a bit like 4 stereo spdif outputs ? so one could get 8 channels with 4 stereo dacs .I assume the idea would be to get 4 cheaper well measuring days for a multiway active speaker system .? is there anyway the channels could be combined within 0ne spdif output then sent to an avr the way all the surround channels could be sent through the same cable . I know i asked this before but I just wanted to be make sure I understood .
appreciate your time to answer.
 
It's a goodie
 
hiya ive been reading through and just wanted to clarify as this is a little bit harder to follow for me . at the moment your adding more physical spliff outputs so a bit like 4 stereo spdif outputs ? so one could get 8 channels with 4 stereo dacs .I assume the idea would be to get 4 cheaper well measuring days for a multiway active speaker system .? is there anyway the channels could be combined within 0ne spdif output then sent to an avr the way all the surround channels could be sent through the same cable . I know i asked this before but I just wanted to be make sure I understood .
appreciate your time to answer.
That is correct. With four SPDIF outputs, users could connect four DACs to produce eight audio channels. I have no doubt that the use cases for this will be quite varied, with some people using it as an active crossover and others simply applying filters to multiple devices or headphones.

The RP2040/2350 doesn't have the resources for the AC-3 encoding that would be required to output multiple compressed channels via SPDIF, so connection to an AVR would have to be done either via multichannel analog inputs or a direct I2S feed. Multi-channel I2S output is also planned but the process of connecting it to an AVR requires circuit modifications to said AVR.
 
That is correct. With four SPDIF outputs, users could connect four DACs to produce eight audio channels. I have no doubt that the use cases for this will be quite varied, with some people using it as an active crossover and others simply applying filters to multiple devices or headphones.

The RP2040/2350 doesn't have the resources for the AC-3 encoding that would be required to output multiple compressed channels via SPDIF, so connection to an AVR would have to be done either via multichannel analog inputs or a direct I2S feed. Multi-channel I2S output is also planned but the process of connecting it to an AVR requires circuit modifications to said AVR.
thanks for clarifying. ill have a look around and see if theres any cheap little dacs where It makes sense cost wise .
 
DSPi v1.0.7 with batch sample processing has passed testing and is now available!

This release introduces an efficiency increase of about 13%, which is equivalent to an additional 15 filters of capacity on core 0. Additionally, the core 0 usage meter now updates continuously, whether or not audio is playing. This enables one to evaluate core usage immediately upon making changes, without the need to play something.

As always, I encourage existing users to stress test the new release and let me know if any oddities (audible or otherwise) are encountered. The USB descriptor bug will be addressed in the next release.

Please note that this release does not have an accompanying DSPi Console update. It is fully compatible with the current DSPi Console v1.0.6.
 
Thank you!

There's a small issue with the USB descriptors at the moment, which prevents Windows from knowing which driver to install for the control interface. Check Device Manager and see if you have a second "Weeb Labs DSPi" with a missing driver. If so, do the following:

Grab this application, launch it and select "Weeb Labs DSPi (Interface 2)" from the dropdown box. Make sure "WinUSB" is selected next to the green arrow and then choose "Install Driver". Give it a few minutes to install.

1770434479622.png




Once installed, everything should be working and you should have two DSPi devices; one under "Sound, video and game controllers" and the other under "Universal Serial Bus devices".

You can then use the DSPi Console application. If it's already running, clicking the reconnect button in the lower left corner should establish a connection to the board.

I'll be issuing a new commit and release with this issue fixed shortly. Support for the Windows light mode is also on the way.

Thanks!
It worked exactly as you said, from Zadig to the two devices that are now OK (one had an exclamation point before).
I can send audio to it now, just need some time tomorrow to solder a SPDIF output and test it.
 
DSPi v1.0.7 with batch sample processing has passed testing and is now available!

This release introduces an efficiency increase of about 13%, which is equivalent to an additional 15 filters of capacity on core 0. Additionally, the core 0 usage meter now updates continuously, whether or not audio is playing. This enables one to evaluate core usage immediately upon making changes, without the need to play something.
Is the core 1 usage pegged to 66% because the software DAC keeps running even if the PDM output is muted?
 
Thanks!
It worked exactly as you said, from Zadig to the two devices that are now OK (one had an exclamation point before).
I can send audio to it now, just need some time tomorrow to solder a SPDIF output and test it.
I'm glad to hear it's working now. I'd love to know how things go tomorrow. :)


Is the core 1 usage pegged to 66% because the software DAC keeps running even if the PDM output is muted?
That is correct. The PDM runs continuously, regardless of audio packets arriving. This will change in the next release, which is when the matrix mixer is being introduced.
 
This is becoming ever greater! Does it support multiple shelving filters overall and per output channel?

Linkwitz used these a lot, and it was the reason I could not use Aurora DSP with the LX521.4, as Aurora only allows for one up and one down shelf per output channel.
 
This has required quite a few refactors and rewrites but the matrix mixer has now been implemented and is working well. I have tested all nine output channels and all are stable. Pins are GPIO 6 to 9, with PDM on 10.

PDM loop now stops when its corresponding channel is disabled. This leaves core 1 completely unused, so we'll be taking advantage of this fact to offload filter computation when available.

Core 1 now exhibits two modes of operation. It is either running the PDM loop for analog subwoofer output or it is handling filter computation for six audio channels. A safety interlock prevents both states from occurring simultaneously while notifying the host of the conflict. My reasoning here is that a user with the hardware to make use of four SPDIF outputs is unlikely to need a PDM output, while those relying on the PDM output likely don't possess the hardware to make use of four SPDIF outputs.

With this new architecture, we leave core 0 with an absolute maximum utilization of just 35%. This frees a plethora of resources for Bluetooth LDAC, SPDIF/I2S input, displays, integrations and other fancy things.
1770700332066.png

This UI design is not remotely final, so don't mind the garish colors. I must now focus on optimization once more.

This is becoming ever greater! Does it support multiple shelving filters overall and per output channel?

Linkwitz used these a lot, and it was the reason I could not use Aurora DSP with the LX521.4, as Aurora only allows for one up and one down shelf per output channel.
@capslock
You may stack shelving filters to your heart's content!
(Tagged in case after-the-fact quote doesn't work)
 
Last edited:
Back
Top Bottom