• 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

I spammed a bit on Discord this morning about a few different things, not sure if you read it all but I'll just lay it out a bit nicer here instead of spamming Discord again :)

-Windows volume settings is affecting the volume when the SPDIF input is in use. I don't know if this is intended, but to me it feels really wrong so here only the master volume should control it.

-The Master Volume doesn't affect the loudness compensation which I really think it should, otherwise SPDIF inputs won't be able to use it.

-The loudness compensation still feels wonky. No matter how I set the Reference SPL it gets way too much at lower volumes. The only way to get it to behave somewhat transparent is to set it at around 30%. Also with it enabled and on lower volumes the inputs clips, not audibly but the meter does. And I still don't understand the moon icon here :P

-When switching tracks or pausing/playing I can hear a very slight crackling noise in the speakers just as it happens.
Also when changing the volume you sometimes hear a very slight click or noise, not sure but this could be because it changes volume instantly from one sample to another instead of with a small fade.

-When pressing on a number field on a filter, it should get all selected so you can just start typing. As of now you have to select it all manually which on a field with a decimals can mean a few extra clicks. Being able to tab between the filters would be nice addition btw :)
 
I spammed a bit on Discord this morning about a few different things, not sure if you read it all but I'll just lay it out a bit nicer here instead of spamming Discord again :)

-Windows volume settings is affecting the volume when the SPDIF input is in use. I don't know if this is intended, but to me it feels really wrong so here only the master volume should control it.

-The Master Volume doesn't affect the loudness compensation which I really think it should, otherwise SPDIF inputs won't be able to use it.

-The loudness compensation still feels wonky. No matter how I set the Reference SPL it gets way too much at lower volumes. The only way to get it to behave somewhat transparent is to set it at around 30%. Also with it enabled and on lower volumes the inputs clips, not audibly but the meter does. And I still don't understand the moon icon here :P

-When switching tracks or pausing/playing I can hear a very slight crackling noise in the speakers just as it happens.
Also when changing the volume you sometimes hear a very slight click or noise, not sure but this could be because it changes volume instantly from one sample to another instead of with a small fade.

-When pressing on a number field on a filter, it should get all selected so you can just start typing. As of now you have to select it all manually which on a field with a decimals can mean a few extra clicks. Being able to tab between the filters would be nice addition btw :)
On the Windows volume / S/PDIF point, I agree it feels wrong for Windows volume to affect S/PDIF input. In my custom test build I have gone the other way and disabled Windows volume/mute control completely. I now rely on the encoder/RF remote as the actual volume control, with Master Volume left as the final ceiling.

The chain I am aiming for is basically:

Input
USB / S/PDIF / tablet / DAP / other source

Device volume
Encoder / RF remote
This is the normal listening volume

Loudness compensation
Follows the encoder/RF listening volume

DSP
PEQ / crossover / routing / filters

Output gain

Master Volume
Final ceiling / protection limit

Outputs
I2S DAC / S/PDIF TX

So the encoder is not acting like a final master limiter. It is the normal listening-volume control. Loudness should follow that because it represents how loud I am actually listening.

Master Volume then stays at the end as a safety ceiling. For example, I can set Master Volume to -10 dB so the system cannot go beyond that, but still use the encoder below that for day-to-day listening. That means the loudness behaviour is not tied to the protection limit.

This also works better for sources that do not have a useful volume path into DSPi, such as S/PDIF, tablets, DAPs, TVs, etc. The source feeds DSPi, then the DSPi-side encoder/remote controls the listening volume, and Master Volume remains the final maximum output cap.

I have put my custom test build here for anyone who wants to look or test:

https://github.com/CrawlingKingSn8ke/DSPi

This is currently based on v1.1.4-beta1 and adds my local control setup:

Rotary encoder volume/source control
RF remote control
GPIO22 status LED
Safe low startup volume
Windows volume/mute ignored

The idea is to use DSPi more like a standalone device:
Encoder/RF remote = normal listening volume
Master Volume = final ceiling / protection limit
There is still the current S/PDIF input bug present, where Windows USB audio activity can disturb S/PDIF input. This has already been replicated by Troy and is expected to be addressed in Beta 2.

So for now, consider this a test branch/build only. I will update it once the S/PDIF input bug has been fixed upstream, then re-test the encoder/RF controls on top of the patched firmware.
 
On the Windows volume / S/PDIF point, I agree it feels wrong for Windows volume to affect S/PDIF input. In my custom test build I have gone the other way and disabled Windows volume/mute control completely. I now rely on the encoder/RF remote as the actual volume control, with Master Volume left as the final ceiling.

The chain I am aiming for is basically:

Input
USB / S/PDIF / tablet / DAP / other source

Device volume
Encoder / RF remote
This is the normal listening volume

Loudness compensation
Follows the encoder/RF listening volume

DSP
PEQ / crossover / routing / filters

Output gain

Master Volume
Final ceiling / protection limit

Outputs
I2S DAC / S/PDIF TX

So the encoder is not acting like a final master limiter. It is the normal listening-volume control. Loudness should follow that because it represents how loud I am actually listening.

Master Volume then stays at the end as a safety ceiling. For example, I can set Master Volume to -10 dB so the system cannot go beyond that, but still use the encoder below that for day-to-day listening. That means the loudness behaviour is not tied to the protection limit.

This also works better for sources that do not have a useful volume path into DSPi, such as S/PDIF, tablets, DAPs, TVs, etc. The source feeds DSPi, then the DSPi-side encoder/remote controls the listening volume, and Master Volume remains the final maximum output cap.

I have put my custom test build here for anyone who wants to look or test:

https://github.com/CrawlingKingSn8ke/DSPi

This is currently based on v1.1.4-beta1 and adds my local control setup:

Rotary encoder volume/source control
RF remote control
GPIO22 status LED
Safe low startup volume
Windows volume/mute ignored

The idea is to use DSPi more like a standalone device:
Encoder/RF remote = normal listening volume
Master Volume = final ceiling / protection limit
There is still the current S/PDIF input bug present, where Windows USB audio activity can disturb S/PDIF input. This has already been replicated by Troy and is expected to be addressed in Beta 2.

So for now, consider this a test branch/build only. I will update it once the S/PDIF input bug has been fixed upstream, then re-test the encoder/RF controls on top of the patched firmware.
Not sure I follow exactly, but what exactly is the encoder/RF remote controlling if not the master volume? Because I actually would like to have a master volume as a final limiter so I don't risk my toddler cranking it up to party volumes, but as it is now I don't see what else to use to change the volume.
 
Not necessarily high SQ amirite?
Certainly not by the standards we expect from DACs. I don't think anyone's measured it yet, but if the original Raspberry Pi's audio output is anything to go by (a PWM (ab)used to make an audio output) it probably distorts less than a lot of subwoofers. For some use cases it'll be perfectly adequate, as well as being nearly free (similar passive cost to those needed for S/PDIF).
 
Certainly not by the standards we expect from DACs. I don't think anyone's measured it yet, but if the original Raspberry Pi's audio output is anything to go by (a PWM (ab)used to make an audio output) it probably distorts less than a lot of subwoofers. For some use cases it'll be perfectly adequate, as well as being nearly free (similar passive cost to those needed for S/PDIF).
The PDM output is really quite clean; especially the new implementation that @slunk is working on. We may soon have multiple PDM channels. :)

1777931739217.png


In other news, per-band bypass controls have been implemented and will appear in the next beta.

1777931901160.png
 
-Windows volume settings is affecting the volume when the SPDIF input is in use. I don't know if this is intended, but to me it feels really wrong so here only the master volume should control it.

What do you mean by that? It's ambiguous.

Do you mean that the Windows volume, when the DSPi is connected to the computer via USB, interacts with the volume of another source connected to the DSPi's SPDIF input? Yes, that is indeed strange.

But if the computer is the source connected via SPDIF, then that's normal. Obviously, in that case, to preserve the quality of the signal processing, it's best to keep the Windows volume at 100% (or bypassed) and manage the volume solely through the DSPi's Volume Master. But occasionally, having the option to adjust the Windows volume can be useful in certain situations... (because you don't always have the DSPi's remote control/dial handy). The only thing that might possibly be possible is to have an option to link (and unlink) the Windows volume controller to the DSPi master... but that would be risky depending on the chain downstream of the DSPi.

-The Master Volume doesn't affect the loudness compensation which I really think it should, otherwise SPDIF inputs won't be able to use it.
This is normal behavior because the master volume only acts at the end of the loop at the DSPi level...
I'm not sure but it seems that in order to have loudness interaction on your SPDIF input, you need to apply a negative preamp at the SPDIF input to leave enough headroom for the loudness application.
 
PDM output is to feed to an analog input via an RC low pass filter. If you want to drive an S/PDIF input then configure the pin as S/PDIF not as PDM
Hey @somebodyelse , @Weeb Labs
We have already changed the configuration pin to S/PDIF, but it is still causing some issues. We have attached the images and are currently facing this problem.
 

Attachments

  • 1777964350738.png
    1777964350738.png
    333.8 KB · Views: 54
  • 1777964385331.png
    1777964385331.png
    383.6 KB · Views: 56
Hey @somebodyelse , @Weeb Labs
We have already changed the configuration pin to S/PDIF, but it is still causing some issues. We have attached the images and are currently facing this problem.
The PDM slot is not supposed to be assignable, so this is a small visual bug with the RP2040. This board can support either two digital output channels and a PDM or four digital output channels and no PDM.

What you need to do is ensure PDM is disabled in the mixer and then use the OUT 3/4 slot for the DAC connected to your subwoofer.
 
The PDM slot is not supposed to be assignable, so this is a small visual bug with the RP2040. This board can support either two digital output channels and a PDM or four digital output channels and no PDM.

What you need to do is ensure PDM is disabled in the mixer and then use the OUT 3/4 slot for the DAC connected to your subwoofer.
thank you :)
 
What do you mean by that? It's ambiguous.

Do you mean that the Windows volume, when the DSPi is connected to the computer via USB, interacts with the volume of another source connected to the DSPi's SPDIF input? Yes, that is indeed strange.

But if the computer is the source connected via SPDIF, then that's normal. Obviously, in that case, to preserve the quality of the signal processing, it's best to keep the Windows volume at 100% (or bypassed) and manage the volume solely through the DSPi's Volume Master. But occasionally, having the option to adjust the Windows volume can be useful in certain situations... (because you don't always have the DSPi's remote control/dial handy). The only thing that might possibly be possible is to have an option to link (and unlink) the Windows volume controller to the DSPi master... but that would be risky depending on the chain downstream of the DSPi.


This is normal behavior because the master volume only acts at the end of the loop at the DSPi level...
I'm not sure but it seems that in order to have loudness interaction on your SPDIF input, you need to apply a negative preamp at the SPDIF input to leave enough headroom for the loudness application.
I mean that when I play from my CD player using SPDIF that volume is affected by the volume on my Windows machine which it definitely shouldn't.

But yeah I guess you're right, I didn't even think about that we have preamps on the inputs! Can't check now myself, but does that affect the loudness compensation? I hope it does!
Edit: I tried it out now, input preamp does not affect loudness compensation.

@Weeb Labs Btw, SPDIF pinout selection does not get saved.
 
Last edited:
There are too many volume controls... Which one should I use to eliminate the risk of digital clipping if I use the equalizer? I.e. PEQ at +3 db and I set the volume to -3 db.
 
There are too many volume controls... Which one should I use to eliminate the risk of digital clipping if I use the equalizer? I.e. PEQ at +3 db and I set the volume to -3 db.

There's largely just two in this case. You would want to reduce the Master Volume on the DSPi interface to compensate for any gain.
 
There are too many volume controls... Which one should I use to eliminate the risk of digital clipping if I use the equalizer? I.e. PEQ at +3 db and I set the volume to -3 db.
If applying PEQ to the input channels, then you adjust the preamp controls for those channels.
 
Actually, we might need to revisit this "preamp" issue. (Besides, this option doesn't exist on any other DSP I know of...)

The idea I'm considering is to automate it entirely based on the PEQ, loudness, and other user settings. This would be completely transparent to the user, and it wouldn't even be necessary to make it manually adjustable or accessible through the interface.

Also, we shouldn't confuse "preamp" and "gain." Gains are necessary and must be adjustable. However, the question I have with the DSPi in its current state is whether the gains are compensated by the volume control algorithm...? I haven't been able to do extensive testing yet due to lack of time, but also because I'm waiting for the DSPi to reach a more advanced stage and to finish developing my own card to meet my specific needs... so I don't have an answer to that question.

But I understand that volume management can be complicated to grasp in the case of a DSP. And perhaps Troy should educate us a bit by explaining his choices on this subject and how everything interacts, in order to eliminate any questions or doubts we might have.
 
If applying PEQ to the input channels, then you adjust the preamp controls for those channels.
Actually, we might need to revisit this "preamp" issue. (Besides, this option doesn't exist on any other DSP I know of...)

The idea I'm considering is to automate it entirely based on the PEQ, loudness, and other user settings. This would be completely transparent to the user, and it wouldn't even be necessary to make it manually adjustable or accessible through the interface.

Also, we shouldn't confuse "preamp" and "gain." Gains are necessary and must be adjustable. However, the question I have with the DSPi in its current state is whether the gains are compensated by the volume control algorithm...? I haven't been able to do extensive testing yet due to lack of time, but also because I'm waiting for the DSPi to reach a more advanced stage and to finish developing my own card to meet my specific needs... so I don't have an answer to that question.

But I understand that volume management can be complicated to grasp in the case of a DSP. And perhaps Troy should educate us a bit by explaining his choices on this subject and how everything interacts, in order to eliminate any questions or doubts we might have.
Volume control is a complex and potentially dangerous topic, especially for our speakers and our hearing.
There are good reasons why most AVRs use digitally controlled analog volume control ICs.

Many of these analog volume control ICs are so good that even modern DACs aren't limited in their performance, for example, the Muses ICs or those from Rohm.
While this would place the volume control after the DAC, it would also avoid many problems.
The control could still be handled centrally via the Pi Pico.

The basic gain setting for the individual drivers should, of course, still be done in the DSP.
 
Actually, we might need to revisit this "preamp" issue. (Besides, this option doesn't exist on any other DSP I know of...)
Sorry, but which option do you mean?

Just like "a DSP" the concept of "a preamp" has gotten muddied these days.

To me it comes down to functionality.

Preamp fundamentally means 1. user ad-hoc volume control, as in boosting line OUTPUT voltage.

Gain is for 2. "gain staging" - a set and forget adjustment to accommodate source INPUTs.

The other fundamental preamp function is 3. switching between those input sources.

Now historically, "a preamp" did both 4. user ad-hoc tone controls, and balance tweaking and also "system-level" set and forget like 5. loudness comp (tied to 1), stereo/mono, high (hiss) or low (rumble) filtering...

ALL these functions CAN now be implemented using DSP technology, but that IMO does not on its own qualify a device as "a DSP" as opposed to "a preamp".

that "a DSP" label requires further "system-level" set and forget functionality, such as A. speaker compensation, B. bass management, signal routing, FR and phase adjustment of crossovers, and C. DRC.

With a tiny inexpensive device like DSPi, it is possible that the A&B functions, plus gain matching, would be implemented with multiple units distributed at different points in the system.

DRC in my opinion is best served with another unit dedicated to just that task.

All the rest of the "preamp functions" could be done with another single unit, or if enough processing power remains, the same one where DRC is implemented.

I would only be OK with that, if the UIs, preset storage etc for the two were kept separate
 
Uh, don't get too carried away, I was only talking about the preamp function on the available inputs on the DSPi.... (knowing that these same inputs also have a "gain" function...)
 
Last edited:
For input gain/preamp, I personally would not touch it unless there is a specific reason. I see input gain as being mainly for headroom or source matching. For example, reducing level before input-side EQ or loudness boost, matching an unusually hot or quiet source, or dealing with analogue-style sources where level can vary more, such as a phono stage, turntable setup or ADC input.

For normal digital sources like USB, S/PDIF from a TV, CD player, DAP or streamer, I would generally leave input gain at 0 dB unless there is clipping or unless EQ is being applied on the input channels.

For speaker/sub integration, I think PEQ and crossovers usually make most sense on the outputs. That is where I would put things like:

High-pass for main speakers
Low-pass for subwoofer
Driver/output-specific correction
Sub level matching
Left/right output correction
Protective filters

So, for example:

OUT1/OUT2 = mains / S/PDIF output correction
OUT3/OUT4 = I2S DAC / sub correction

Input PEQ makes more sense for things you want applied before the signal is split or routed. For example, a global correction, source-specific correction, or a house curve that should affect both the mains and sub together.

But for mains/sub work, input PEQ can become awkward because it affects everything downstream. If I only want to correct the mains, or only the sub, output PEQ is the more logical place.

Master Volume at the end is still useful as a final protection ceiling, but I would not rely on it alone for internal DSP headroom. It can stop the final output going above a set limit, but it does not necessarily solve clipping earlier in the processing chain.

Control path:
Encoder / RF remote

DSPi host/listening volume value

Loudness compensation uses this value as its listening-level reference

Then in the audio path, that same host/listening volume is also used as part of the final output scaling, together with Master Volume:

Audio path:
Input
USB / S/PDIF

Input gain / preamp, if needed

DSP processing
PEQ / crossover / routing / loudness

Output gain / channel matching

Final output scaling
Host/listening volume × Master Volume

Outputs
I2S / S/PDIF TX
 
Last edited:
Back
Top Bottom