giubeppe
Member
- Joined
- Nov 6, 2024
- Messages
- 13
- Likes
- 19
In general I agree with you, though in the long term I’m planning to connect to one of these https://www.audiophonics.fr/en/inte...t-to-hdmi-i2s-lvds-output-module-p-13418.html
-
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
- Thread starter Weeb Labs
- Start date
Sonic-Wall
Active Member
- Joined
- Mar 29, 2021
- Messages
- 102
- Likes
- 79
Sonic-Wall
Active Member
- Joined
- Mar 29, 2021
- Messages
- 102
- Likes
- 79
Actually, I used a similar module in the past, and it worked great to connect a streamer with an HDMI-I2S output and a DIY board with an I2S input.
I2S is the perfect interface for DIY.
Would this have any advantage over the current toslink output at 24/48?
- Thread Starter
- #565
Thank you! I will squash this bug in the next Console release.
TurtlePaul
Major Contributor
The primary benefit of I2S output would be the ability to connect devices that don’t support SPDIF, such as this HDMI board or certain DAC boards.
Got mine set up - cool little project. Can't wait for SPDIF input support 
I performed latency measurements using a Beagle USB analyzer, scope, DAC, and some custom scripting to decode the captured USB traffic.
Latency is measured from the point that audio data is transmitted over USB to analog output from a DAC, bypassing any buffering in the PC entirely.
The DAC (some cheap generic SPDIF DAC from Amazon) I measured separately on Audio Precision and found it adds ~300us latency to the signal path.
Tested FW v1.1.1 at 48Khz sample rate. All filters disabled.
With the DSPi, I'm getting anywhere from 4-13ms latency, slowly dropping by about 7us/s.
Occasionally, the latency will shoot back up to some value in the aforementioned range. I don't see any underruns counted in the stats from the DSPi Console when this occurs.
Latency also changes each time the USB playback is restarted.
Enabling some EQ filters didn't seem to change the behavior.
I am able to measure consistently +/- 1us with this setup on some other USB audio devices, for reference.
I performed latency measurements using a Beagle USB analyzer, scope, DAC, and some custom scripting to decode the captured USB traffic.
Latency is measured from the point that audio data is transmitted over USB to analog output from a DAC, bypassing any buffering in the PC entirely.
The DAC (some cheap generic SPDIF DAC from Amazon) I measured separately on Audio Precision and found it adds ~300us latency to the signal path.
Tested FW v1.1.1 at 48Khz sample rate. All filters disabled.
With the DSPi, I'm getting anywhere from 4-13ms latency, slowly dropping by about 7us/s.
Occasionally, the latency will shoot back up to some value in the aforementioned range. I don't see any underruns counted in the stats from the DSPi Console when this occurs.
Latency also changes each time the USB playback is restarted.
Enabling some EQ filters didn't seem to change the behavior.
I am able to measure consistently +/- 1us with this setup on some other USB audio devices, for reference.
Last edited:
- Thread Starter
- #568
Thank you very much for the measurements!Got mine set up - cool little project. Can't wait for SPDIF input support
I performed latency measurements using a Beagle USB analyzer, scope, DAC, and some custom scripting to decode the captured USB traffic.
Latency is measured from the point that audio data is transmitted over USB to analog output from a DAC, bypassing any buffering in the PC entirely.
The DAC (some cheap generic SPDIF DAC from Amazon) I measured separately on Audio Precision and found it adds ~300us latency to the signal path.
Tested FW v1.1.1 at 48Khz sample rate. All filters disabled.
With the DSPi, I'm getting anywhere from 4-13ms latency, slowly dropping by about 7us/s (1 sample every 3 seconds at 48Khz, if my math is right).
Occasionally, the latency will shoot back up to some value in the aforementioned range. I don't see any underruns counted in the stats from the DSPi Console when this occurs.
Latency also changes each time the USB playback is restarted.
Enabling some EQ filters didn't seem to change the behavior.
I am able to measure consistently +/- 1us with this setup on some other USB audio devices, for reference.
I believe your observations are a result of the current USB feedback implementation. I mentioned previously that my design latency is around 10ms but it can vary depending upon buffer fill and drain levels. Crucially, samples are never dropped.
When I have more free time this weekend (after SPDIF input is working), I will spend some time investigating the USB feedback to see if we can tighten a few screws.
giubeppe
Member
- Joined
- Nov 6, 2024
- Messages
- 13
- Likes
- 19
Ok @Sonic-Wall I merged Weeb Labs' changes into the code and with the help of my AI intern I enabled 24 bit on I2S.
Binary here: https://github.com/giubeppe/DSPi/blob/refactor/Binaries/rp2350-24bit.uf2
Please note, I'm not checking if the other SPIDF outputs are still working and neither I can validate if the output is really 24 bit. Would you be able to on your side, please let me know.
- Thread Starter
- #570
Just a heads up. If you merged the updated USB descriptors, please check the repository again as there was an important commit that I had forgotten to push until just now.
With the second alt mode for 24-bit input, the configuration descriptor is three bytes in length and requires a ZLP. The pico-extras SDK doesn't automatically append it for three byte descriptors, so it I've had to add that functionality to the usb_device module myself. Without that commit, everything works under macOS but Windows waits for the ZLP until eventually timing out.
The latest v1.1.1 release includes this commit, incidentally.
giubeppe
Member
- Joined
- Nov 6, 2024
- Messages
- 13
- Likes
- 19
Thanks, I'll check that out. BTW, I don't know if it was a problem on my side or else, but I had issues with 96kHz 24bit and had to make some changes to make it work. Not sure that is related or not.
While I'm at it, I measured the jitter on the SPDIF output on APx555 as well.
With music playing, it ranges from 250-300 ps.
Well within typical range for SPDIF (<500ps from a quick Google).
No significant change with or without filters enabled.
I also found that for some reason, turning matrix mixer outputs on/off can cause the APx555 to disconnect from the PC.
Probably some quirk of the AP, I've had similar happen when launching certain software such as UsbTreeView.
With music playing, it ranges from 250-300 ps.
Well within typical range for SPDIF (<500ps from a quick Google).
No significant change with or without filters enabled.
I also found that for some reason, turning matrix mixer outputs on/off can cause the APx555 to disconnect from the PC.
Probably some quirk of the AP, I've had similar happen when launching certain software such as UsbTreeView.
- Thread Starter
- #573
Thanks again for measuring. I'm glad to see that the output jitter is close to my estimates.
- Joined
- Feb 26, 2020
- Messages
- 223
- Likes
- 283
I made some progress testing a Waveshare ESP32-C6-LCD-1.4 display I had around, attached to the DSPi using UART (I2C planned), with a quick firmware with a LVGL UI.
My conclusions:
- the display looks great to me (for ~12$/€); I feel like one display can be enough to show even two level meters. I now see no reason to use the outdated OLED display (~2$/€).
- On the other hand, I don't think that the touch-enabled version would work for me: it's too small and it adds cost. I think a rotary encoder would be enough for small config/profile/volume changes.
- Waveshare has a very similar version based on a RP2350. The CPU load in my ESP MCU is heavily dependant on the update rate. I'm thinking that slightly lowering it would allow for that MCU board to run DSPi along with a simple LVGL UI.
My conclusions:
- the display looks great to me (for ~12$/€); I feel like one display can be enough to show even two level meters. I now see no reason to use the outdated OLED display (~2$/€).
- On the other hand, I don't think that the touch-enabled version would work for me: it's too small and it adds cost. I think a rotary encoder would be enough for small config/profile/volume changes.
- Waveshare has a very similar version based on a RP2350. The CPU load in my ESP MCU is heavily dependant on the update rate. I'm thinking that slightly lowering it would allow for that MCU board to run DSPi along with a simple LVGL UI.
I'm actually designing a board that has an RP2350 and a codec, that can be used as a crossover. So I2S support in DSPi would mean that you can do stereo analog in - codec (ADC) - DSPi - 4/6/8 channel I2S out - codec (DAC) - analog out. Or SPDIF in - DSPi - i2s - codec.
highlander
New Member
- Joined
- May 23, 2023
- Messages
- 1
- Likes
- 0
I tried the 1.1.1 release. For me, 96kHz 24bit crackles, but it works fine at 16bit.
- Thread Starter
- #577
96KHz at 24-bit is untested at the moment. As mentioned previously, I will continue to include the 96KHz option but it is not a priority, as it halves the number of DSP instructions available without providing any audible benefit.
Exactly what I was beginning to mull. Which codec were you thinking of? I was pondering stereo DACs, either AK4493S, which is cheap and capable of very good performance, certainly better than most codecs I'm aware of, or ES9039QN, which is still reasonably priced, has I2S and SPDIF in and excellent performance, better even than the 8 channel 9039PRO, which has an issue with 10 kHz THD according to @IVX.
Last edited:
Not what I would have expected. The sample rate sets the DSP load, and going from 24 to 16 bits shouldn't make a difference as one needs more than 16 bit word length anyway. So how to explain?
- Thread Starter
- #580
If memory serves, sample rate switching above 48KHz is not yet handled at 24-bit. I will address this in the next release.
