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

[staticV3]

When can we expect the MacOS version?

Wdym?

DSPi has been available for macOS from the very beginning.

- DSPi Console (macOS)

 

[markz]

Unfortunately I'm not an electrical engineer. Really hoping someone will design a board that can be used for active speakers. A board that can host 4x pcm dac and some inputs like toslink and ADC. Would be nice as a group buy.

I have this board that hosts 4 I2S ports and an optical input along with another board for wiring up three DACs (my speaker size). They cost me 80cents each as bare boards and a few dollars with the connectors. I've got three left over I'm not using if you want to msg me. Note the boards do not have the Pico or the optical input.

 

[Tell]

I have this board that hosts 4 I2S ports and an optical input along with another board for wiring up three DACs (my speaker size). They cost me 80cents each as bare boards and a few dollars with the connectors. I've got three left over I'm not using if you want to msg me. Note the boards do not have the Pico or the optical input.
View attachment 540085View attachment 540082View attachment 540084

Nice ones, you designed them yourself?

 

[Weeb Labs]

Wdym?

DSPi has been available for macOS from the very beginning.

I believe he is asking about the v1.1.5 beta update for macOS, which I hope to release later this evening.

 

[robca]

I havent built mine yet because the second I wire it all up, someone will finish their pcb with everything already on it

Hurry up already and bodge-wire yours, so that we can all benefit from the new PCB

 

[beaker152]

Yes. The number of filters per channel has a SET/GET command. Any number of filters can be placed on any channel, so long as they fit within the total budget of 100.

does that mean that if i am only using the master L/R channels (i have a simple setup) that number of filters for those channels could be set to, say, 20 as long as two other unused channels get their number of filters reduced from 10 down to zero?

 

[beaker152]

The current roadmap is now available on the repository.

## v1.1.3
- Three-channel stereo (mid/side)
- USB communication optimizations
- User-configurable GPIO for parameter control (volume, tone, crossfeed, etc.)

@Weeb Labs just curious if the GPIO functionality for parameter control made it into the release? i didn't recognize it in any of the docs on github, but could easily have missed it, though i do see loudness control available in dspictl.

context: for my use case, i'd like to keep volume control on my external pre-amp and use a GPIO pin to control the loudness compensation from another gadget/microcontroller that reads the pre-amp volume setting, perhaps similar to what @Kingsnake did in https://www.audiosciencereview.com/...-less-than-a-cup-of-coffee.69343/post-2569616

 

[john61ct]

I saw a kludge done via python scripting somewhere.

Personally V+LC needs to be a physical knob at LP and ideally also (to the same control) via my phone

Pre-amps with Loudness - OSD Pre-1 ?

Most of my source-switchers and volume controls are analog-only, which is my preference. I am also frugal, some months actually poor 8-( I like having physical tone controls, and miss the old variable loudness curve feature, ideally automatically coupled with the volume level, but I guess that...

www.audiosciencereview.com

Definitely integrated / automatic not a separate control.

 

[The Capstan]

I am delighted to announce that I2S input is now fully functional and currently being tested.

This weekend's v1.1.5 beta release will include not only the complete suite of crossover filters but I2S input as well.

View attachment 538844

Hi Troy,
First of all, congratulations on your work. I am really impressed by what you are developing.

I am currently preparing a webinar series on digital audio and streamers, and one of the episodes will cover digital interfaces, namely I²S, S/PDIF over coax/Toslink, AES/EBU and USB Audio Class. Since you clearly have deep practical experience in this area, I wanted to ask you a question about how I²S timing is managed in your Raspberry Pi-based DSP implementation.

One thing I recently found interesting is that, in the official NXP I²S specification, timing ownership is not necessarily tied to the audio source. The device generating SCK and WS is the “controller”, and this role can be assigned to the transmitter, to the receiver, or even to an external controller.
Looking at your screenshot, I see several settings related to BCK, MCK, the MCK multiplier and the I²S input configuration. So I was wondering: in your implementation, who actually owns the I²S timing? Does the Raspberry Pi/DSP generate BCK/SCK and WS, or can the timing be provided by an external precision clock, by the connected I²S source, or even by the DAC/receiver side?

May I also take advantage of what seems to be your in-depth knowledge of this subject to ask a related question - although slightly off topic, sorry. As far as you know, in external DACs using I²S over an HDMI connector, is the connection generally source-clocked, with the streamer acting as the I²S controller, or do some DAC implementations allow the DAC/receiver side to own the timing?
This is one part of my presentation where I still need some more clarity.

Thanks in advance, and again congratulations for this excellent open-source project.

 

[Weeb Labs]

Hi Troy,
First of all, congratulations on your work. I am really impressed by what you are developing.

I am currently preparing a webinar series on digital audio and streamers, and one of the episodes will cover digital interfaces, namely I²S, S/PDIF over coax/Toslink, AES/EBU and USB Audio Class. Since you clearly have deep practical experience in this area, I wanted to ask you a question about how I²S timing is managed in your Raspberry Pi-based DSP implementation.

One thing I recently found interesting is that, in the official NXP I²S specification, timing ownership is not necessarily tied to the audio source. The device generating SCK and WS is the “controller”, and this role can be assigned to the transmitter, to the receiver, or even to an external controller.
Looking at your screenshot, I see several settings related to BCK, MCK, the MCK multiplier and the I²S input configuration. So I was wondering: in your implementation, who actually owns the I²S timing? Does the Raspberry Pi/DSP generate BCK/SCK and WS, or can the timing be provided by an external precision clock, by the connected I²S source, or even by the DAC/receiver side?

May I also take advantage of what seems to be your in-depth knowledge of this subject to ask a related question - although slightly off topic, sorry. As far as you know, in external DACs using I²S over an HDMI connector, is the connection generally source-clocked, with the streamer acting as the I²S controller, or do some DAC implementations allow the DAC/receiver side to own the timing?
This is one part of my presentation where I still need some more clarity.

Thanks in advance, and again congratulations for this excellent open-source project.

Hello and thank you for the kind words!

In the current implementation, the Pico is the clock master and generates all I2S clocks. It is possible to supply external clocks and for the Pico to operate in slave mode but this is not yet part of the firmware.

Many I2S devices (DACs, ADCs, other DSPs) can be configured to function either as a clock master or slave, with the former typically necessitating an onboard crystal oscillator.

Regarding I2S over HDMI connectors (often buffered as LVDS), there is no actual standard for this and pin allocations vary widely by manufacturer. The vast majority of DACs that accept I2S via HDMI connector operate in slave mode but this is by no means a requirement.

 

[Weeb Labs]

DSPi Firmware and Console for macOS v1.1.5-beta2 are now available.

This beta squashes a few bugs and introduces a few new additions.

Here is the list of changes:

• RP2350: All first order crossover filters now make use of the hybrid SVF architecture
• RP2350/2040: First order High Shelf, Low Shelf and All-Pass PEQ filters are now available
• RP2350/2040: A new UAC1 audio input device interface has been added, enabling direct bit-perfect capture of output slot 1. Currently experimental and gated behind a build flag.
• Repo: The firmware testing harness has been expanded to include fully autonomous loopback measurement and verification of all DSPi audio functions (including filter responses). This makes use of the new audio input device.
• Console (macOS): Output channel page UI overhauled to support the crossover tab
• Console (macOS): Settings menu overhauled to improve discoverability and ease of access
• Console (macOS): I2S input support
• Console (macOS): Clicking the Bypass All button on the crossover tab now triggers a warning and confirmation prompt
• Console (macOS): Shelving and all-pass filters now provide a selection of orders via submenu and High/Low pass PEQ filters are now High/Low Cut
• Console (macOS): The Output Configuration global parameter is now "Hardware Configuration" in order to more accurately reflect its function.

For the next beta, the Master Volume function is receiving an overhaul. It will instead become "Volume Limit", with a far more intuitive implementation.

As always, please don't hesitate to report any bugs that you encounter; that's how we squash them! You can do that either here, on GitHub or via Discord (many helpful people there). If you wish to support the project, you can also do that via Ko-fi.

 

[zergxia]

After refreshing to the v1.1.5 - beta2 firmware, can the Windows console v1.1.5 - beta1 work properly ?

 

[Weeb Labs]

After refreshing to the v1.1.5 - beta2 firmware, can the Windows console v1.1.5 - beta1 work properly ?

It should work but I would recommend waiting for the Windows update.

 

[markz]

There's been some interest in how the PCM5102 sounds and so I did some quick tests of three different PCM5102 (or 5122) boards. My top-line summary is that the three boards test pretty different but ultimately probably sound identical. I used a QA403 and a DSPi to test with on a Windows desktop. I used QA40xPlot to test and display the results.

The 5102 and 5122 have the same audio circuitry and the 5122 adds the ability to program an internal crossover/filter via I2C. The three boards I tested:

Left to right->
1) Something I whipped up to test the PCM5122 with 'better' conditions named "mz". It has a different capacitor complement and uses a 1/4" plug.
2) The 'purple' PCM5102. I bought mine on Amazon but there must be 20 vendors with the same looking boards. It's the smallest board and the miniplug socket is awful and really cheap. I was unable to get the left channel to work so didn't do a crossover test. This is the one being tested in the photo above.
3) The Adafruit PCM5122 board. Their online doc is awesome (with a schematic and pcb layout) and it has a way better miniplug socket but does cost more.

So, here are the tests I did. For the spectral tests - the mz board is shown on top in bright green, the Adafruit board is second with purple graph lines, and then the purple board is shown last with blue graph lines. Note the Legend. The intermod test is pretty interesting, the others show negligible audible differences.

Mark

 

[zergxia]

Recently I’ve tested and modded a low-cost DAC with optical input, and figured some folks here might be interested in my findings.
This unit comes in a cheap all-aluminum chassis instead of a bare PCB. It accepts optical and coaxial digital inputs, features single-ended RCA analog outputs, and runs off a standard 5V USB power supply.

I set up a simple measurement chain as follows:
PC → USB → DSPi → Optical Out → Test DAC → RCA Analog Out → ADC → USB → PC

My initial measurements revealed poor distortion performance across several frequency bands. After taking the unit apart to inspect the PCB, I noticed the output coupling capacitors were not tantalum electrolytics as pictured in the product listing—instead, the manufacturer fitted 47 µF ceramic capacitors.

I suspected these 47 µF ceramic caps were the root cause of the degraded audio performance. I replaced the output coupling capacitors with electrolytic equivalents (critical note: observe polarity; there is a 1.65 V DC bias present at this node). I also swapped the two 22 nF ceramic capacitors on output channel for equal-value C0G types at the same time.

After this straightforward mod, I reran the measurements. The distortion improved by 20–30 dB!

It has two minor flaws:
1. The DAC overloads when fed a full-scale digital input signal. Optimal performance is only achieved after attenuating the digital level down to below -6 dB, whereas typical high-performance DACs deliver their best performance at just -0.5 dBFS.
2. The frequency response plot shows a gradual 3 dB roll-off at the 20 kHz high-frequency end.

Considering its ultra-low price tag, these two drawbacks are totally manageable, and its overall performance exceeded my expectations by quite a margin!

 

[Weeb Labs]

Here's a little peek into the future.

 

[zergxia]

Here's a little peek into the future.

View attachment 540904 View attachment 540903

WOW~ What is this? Is it 8-channel I2S output?

 

[Weeb Labs]

WOW~ What is this? Is it 8-channel I2S output?

This is 8-channel USB (and soon I2S) input. We already have 8-channel I2S output!

 

[gadget-man]

Hi Troy

Of course, I’m not the first person (on p. 89 of this forum) to congratulate you on this awesome project... but I’m doing it anyway, and I hope you get the recognition you deserve!

I’ve been fascinated by the Raspberry Pi and Pico for a while now, so I’ve ordered from Pimoroni tools, boards, displays quite a few times (it works well even from Switzerland). Last night, I discovered the “Pico Audio Pack” in my grab bag, popped an RP2040 into it, and changed:

I2S_DATA = GPio 9
I2S_BCK = GPio 10 >> I2S_LRCK = GPio 11
and it worked right away
> Now anyone can build a DSP sound card for less than £20 without a soldering iron—that’s just great!

P.S. My soldering iron is hot—I still have a few DSPi audio projects lined up.

 

[Sonic-Wall]

The DSPi is always the clock master. When the input and output are both I2S devices configured in slave mode, the same bit clock, word clock and master clock (where applicable) should be connected to both devices.

I do have an input board with coax, optical, and I2S inputs. Since the board has its own oscillator it provides a four-pin I2S signal including MCK at its output.
Unfortunately the input board cannot configured in slave mode, which is also typical for sources such as streamers.
Hence, this is a limitation of the I2S input of the DSPi.
Are there any plans to implement an I2S input that supports input devices acting as a master?