• 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

Here's the suggested PWM filters from the RPi folks

1774219141803.png
 
I wish REW had a more elegant way to set the number of filters to use
Maybe one day REW will have a preset for DSPi.

Troy ( @Weeb Labs ), great project. This is what ASR is really about. It's gratifying to see your dedication and skill in action. If you want REW to support DSPi directly, PM John Mulcahey ( JohnPM here on ASR. I didn't include the '@' sign in his user handle since I don't want to be the one to call him out on this. ) or over on AVNirvana. You guys are both top-notch programmers and will be able to work out the details to include the support in REW for the benefit of all. Thanks.
 
Could you please verify that you have enabled and routed audio to the SPDIF 2 outputs in the matrix mixer? I tested this a moment ago (1.1.2b-hotfix1/2) and all four SPDIF outputs are working for me.
I confirm this is/has been the case. SPDIF 2 appears as active, the audio bars move at unison for SPDIF 1 and SPDIF 2. Identical settings for v1.1.2b yield audio on SPDIF 2, no audio on hotfix versions. Switching back and forth between firmware version consistently shows this (ok for v1.1.2b, nok for v1.1.2b hotfix and hotfix2). Tested on 2 different RP2350s.

1774250267276.png

1774250396405.png


That said, I've done some further testing with v1.1.2b-hotfix2:
- Same symptoms with Topping D90SE and Topping E30 II Lite DACs. Neither is able to lock in on Toslink audio stream via SPDIF 2, no problem whatsoever with SPDIF 1
- After leaving everything connected and music playing for a few minutes, I've got audio via SPDIF 2 on D90SE, but it lasted only 10 secs or so
- No issues with an ultra-cheap low performance tiny DAC box (have not opened it, but given price and performance I assume based on MS8413 integrated receiver and DAC chip).

I've been reading that Topping DACs are more sensitive to the quality of SPDIF signal they receive (high jitter sensitivity issues?), this could explain why you are unable to reproduce the issue. Maybe it's a fringe effect, maybe the TOSLINK transmitters I'm using (cheap no-names) are less robust and combined with Topping DACs are not playing well, but I have absolutely no issues with earlier firmware versions...
 
Last edited:
The only thing that seems possible is the change made to the SPDIF buffer:
"RP2350/2040: Changed 4x192 SPDIF consumer buffers to 16x48, which reduces latency wander to 1ms."

And indeed, it's possible that the Topping's SPDIF interface is more sensitive to this. Too low a latency or a different buffer management can cause synchronization losses, and if the DAC doesn't handle small buffers or very low latency well, it might interpret this as a transmission error.
 
The only thing that seems possible is the change made to the SPDIF buffer:
"RP2350/2040: Changed 4x192 SPDIF consumer buffers to 16x48, which reduces latency wander to 1ms."
My thoughts exactly. Although I find it strange that SPDIF 1 (GPIO 6) has no issues, even after this change.
 
Yes, it's unusual... and have you tried it with GPIO 8 AND 9?
(And one more thing, just in case, are your DAC firmwares up to date?)
 
The buffer change only affects internal handling of samples; transmission still takes place in accordance with the SPDIF standard (192 sample blocks).

I will investigate further to see if something might be amiss with the channel status bits.
 
Yes, it's unusual... and have you tried it with GPIO 8 AND 9?
(And one more thing, just in case, are your DAC firmwares up to date?)
I have not played with the physical board connections yet. Since the effect is so net (absolutely no issue with the previous firmware versions), I don't expect this to make any difference. But I can cover that once I find a bit of time.

I did try something in the meantime:
- Temporarily re-routed SPDIF 1 to GPIO 5 (so that GPIO 6, which worked so far irrespective of firmware version, is available)
- Disabled SPDIF 1 from matrix mixer
- Re-routed SPDIF 2 to GPIO 6. Optic fibre cable connected to the correct (GPIO 6) Toslink transmitter
No sound.

Re-enabled SPDIF 1 in matrix mixer and assigned it to GPIO 7.
I get sound from GPIO 7-connected Toslink transmitter. Still no sound from GPIO 6.

So hardware seems to be absolutely fine, based on this test both Toslink transmitters behave identically. Bizarrely, the system seems to favor SPDIF 1, no matter the physical connection (GPIO 6 or GPIO 7). SPDIF 2, even when activated in isolation, would not work, irrespective of GPIO pin.

D90SE runs the latest firmware version. E30 II was purchased one week ago, have not checked but it must be running a fairly recent firmware version I'd imagine. But again, since they work absolutely fine with prior versions of dspi, I'd not expect this to play an important role here.
 
I have not played with the physical board connections yet. Since the effect is so net (absolutely no issue with the previous firmware versions), I don't expect this to make any difference. But I can cover that once I find a bit of time.

I did try something in the meantime:
- Temporarily re-routed SPDIF 1 to GPIO 5 (so that GPIO 6, which worked so far irrespective of firmware version, is available)
- Disabled SPDIF 1 from matrix mixer
- Re-routed SPDIF 2 to GPIO 6. Optic fibre cable connected to the correct (GPIO 6) Toslink transmitter
No sound.

Re-enabled SPDIF 1 in matrix mixer and assigned it to GPIO 7.
I get sound from GPIO 7-connected Toslink transmitter. Still no sound from GPIO 6.

So hardware seems to be absolutely fine, based on this test both Toslink transmitters behave identically. Bizarrely, the system seems to favor SPDIF 1, no matter the physical connection (GPIO 6 or GPIO 7). SPDIF 2, even when activated in isolation, would not work, irrespective of GPIO pin.

D90SE runs the latest firmware version. E30 II was purchased one week ago, have not checked but it must be running a fairly recent firmware version I'd imagine. But again, since they work absolutely fine with prior versions of dspi, I'd not expect this to play an important role here.
Could you please test this build and let me know if it addresses the issue for you? It would also be very helpful to know if SPDIF 3 and 4 are affected.
 

Attachments

Last edited:
Could you please test this build and let me know if it addresses the issue for you? It would also be very helpful to know if SPDIF 3 and 4 are affected.
With v1.1.2b hotfix 2, issues were present with SPDIF 3 and 4. SPDIF 3 is semi-working, with glitches and constant (long) interruptions. SPDIF 4 no sound.

With the version you shared, all seems fixed! Been testing it for 5 mins now, no issues with SPDIF 1/2/3/4. Impressive!
 
With v1.1.2b hotfix 2, issues were present with SPDIF 3 and 4. SPDIF 3 is semi-working, with glitches and constant (long) interruptions. SPDIF 4 no sound.

With the version you shared, all seems fixed! Been testing it for 5 mins now, no issues with SPDIF 1/2/3/4. Impressive!
I'm glad to hear that it is now fixed. The problem was that in the new buffer architecture, each 192 sample block is split across four buffers rather than just one. The channel status bits would previously have had fixed positions within that block but can now end up in any position across multiple buffers and be read as zero at output. Some DACs don't like that, which is why your Topping refused to lock but the cheaper DAC worked.

The solution was simply to stamp correct channel status bits for every subframe. I'll commit this and push a hotfix shortly. :)
 
Last edited:
Hi, I bought 2 pico 2 (RP2350), and I installed latest DSPI firmware.
Windows 10 and 11 recognise the DSPi (" Weeb labs DSPi" in windows usb list).
Therefore when I start the windows software 'DSPi console' the DSPi is not connected the following message is provided ;"no usb devices visible to L..."
What is missing in windows configuration or is it a bug in 'DSPi console' windows version.
I tryed with WIN 10 and 11 with several pc's and 2 PICO 2.
 
Last edited:
Hi, I bought 2 pico 2 (RP2350), and I installed latest DSPI firmware.
Windows 10 and 11 recognise the DSPi (" Weeb labs DSPi" in windows usb list).
Therefore when I start the windows software 'DSPi console' the DSPi is not connected the following message is provided ;"no usb devices visible to L..."
What is missing in windows configuration or is it a bug in 'DSPi console' windows version.
I tryed with WIN 10 ans 11 with several pc and 2 PICO 2.
Please grab this application and select "Weeb Labs DSPi (Interface 2)" from the dropdown box. Make sure "libusb_win32" (not WinUSB) is selected next to the green arrow and then choose "Install Driver". Give it a few minutes to install.

1770434479622.png




Once installed, you should have two DSPi devices; one under "Sound, video and game controllers" and the other under "libusb-win32".

You can then use the DSPi Console application. This has been a persistent bug that only occurs for some people but should be patched soon.
 
Hi Troy, have you already determined which GPIO pins will be dedicated to SPDIF inputs?
I know it's possible to assign any GPIO pins you want, but practically speaking, which ones will be automatically assigned?
 
Hi Troy, have you already determined which GPIO pins will be dedicated to SPDIF inputs?
I know it's possible to assign any GPIO pins you want, but practically speaking, which ones will be automatically assigned?
SPDIF input will most likely default to GPIO 5.

I2S output is now functional, complete with live output type and pin assignment. As always for brand new functionality, this UI is absolutely not final. It is just functional enough for me to test each component to destruction. :)

Any output slot can now be assigned either to SPDIF or I2S. Master clock output is available in 128 x Fs and 256 x Fs formats through a dedicated state machine, with the former being jitter-free at 48KHz.

1774331472022.png
1774331742485.png

The same buffer configuration is used for both SPDIF and I2S output, so we can get away with a single feedback servo. I am loading the I2S and SPDIF PIO programs into the same four state machines, with teardown and reconstruction logic to ensure a clean state following each change. All output buffer fills are kept perfectly synchronized.
 
Last edited:
This is huge! MCLK disabled means it's an input, so it can come from a separate oscillator? How "clean" is MCLK generated by the RP?
 
Back
Top Bottom