Not necessarily high SQ amirite?PDM output is to feed to an analog input via an RC low pass filter.
Not necessarily high SQ amirite?PDM output is to feed to an analog input via an RC low pass filter.
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.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
-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![]()
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.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.
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).Not necessarily high SQ amirite?
The PDM output is really quite clean; especially the new implementation that @slunk is working on. We may soon have multiple PDM channels.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).
-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.
This is normal behavior because the master volume only acts at the end of the loop at the DSPi level...-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.
Hey @somebodyelse , @Weeb LabsPDM 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
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.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.
thank youThe 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.
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.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.
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.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.
Volume control is a complex and potentially dangerous topic, especially for our speakers and our hearing.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.
Sorry, but which option do you mean?Actually, we might need to revisit this "preamp" issue. (Besides, this option doesn't exist on any other DSP I know of...)