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

[mirkoseghezzi]

Hello everyone,

First of all, I would like to compliment the author of the post for the excellent project—truly impressive work!

I recently purchased a Pico2 (model M with 4MB of memory), and by following the instructions I have:

1. Connected the Pico to my PC while holding down the BOOTSEL button
2. Copied the firmware v1.1.2b onto the Pico
3. The Pico disappears from the system and the audio device “Weeb Labs DSPi” appears
4. Downloaded DSPi Console v1.1.2b
5. Extracted all the contents of the archive and opened the file DSPi Console.exe

Here is where the issue arises: the program does not detect any connected USB device.

I have repeated the same procedure on another Windows PC, but I get the same result. On both computers, when the Pico is connected, the “Weeb Labs DSPi” audio device is correctly recognized by the system.

Could someone more experienced help me resolve this issue?

Thank you in advance.

 

[JuanjoS]

I've figured out that pin resets when "Include Pin Configuration" is not enabled in presets, maybe it should be enabled by default
So, only filling buffer level bug is real bug report here for RP2350

I see the same underruns when sample rate is 44.1Khz on 48Khz works fine.

 

[Red_Red]

Hello everyone,

First of all, I would like to compliment the author of the post for the excellent project—truly impressive work!

I recently purchased a Pico2 (model M with 4MB of memory), and by following the instructions I have:

1. Connected the Pico to my PC while holding down the BOOTSEL button
2. Copied the firmware v1.1.2b onto the Pico
3. The Pico disappears from the system and the audio device “Weeb Labs DSPi” appears
4. Downloaded DSPi Console v1.1.2b
5. Extracted all the contents of the archive and opened the file DSPi Console.exe

Here is where the issue arises: the program does not detect any connected USB device.

I have repeated the same procedure on another Windows PC, but I get the same result. On both computers, when the Pico is connected, the “Weeb Labs DSPi” audio device is correctly recognized by the system.

Could someone more experienced help me resolve this issue?

Thank you in advance.

Welcome, and see the procedure here : https://www.audiosciencereview.com/...-less-than-a-cup-of-coffee.69343/post-2551562

 

[Weeb Labs]

I've observed that this happens when buffer fill levels are filling to 100% for spdif outs that are disabled in this case, BUT only when i select 16bit/44.1 output.
Selecting 24bit/48 buffer levels are constant at 50% and no self reset

View attachment 521544

Thank you very much for this helpful feedback. The problem is a small rounding difference between the I2S and SPDIF libraries that only becomes a problem at 44.1KHz. I will be sorting this out shortly.

 

[sam_adams]

Amir, this may have been mentioned before, if so I apologise, but please consider this young man for 'technical expert'. This is very impressive work.

Just to amplify this since there wasn't a proper callout (no '@' sign in front of the name), @amirm or @RickS, please elevate @Weeb Labs to Technical Expert for the excellent work that he is doing. Thanks from all of us.

 

[Weeb Labs]

I have just pushed DSPi Firmware v1.1.3-beta2, which fully addresses the buffer fill/drain issue at 44.1KHz. I look forward to hearing from our I2S testers!

Next, I am setting my sights on the USB descriptor bug. Manual driver installations via Zadig should be completely unnecessary.

 

[cedo_n]

I have just pushed DSPi Firmware v1.1.3-beta2, which fully addresses the buffer fill/drain issue at 44.1KHz. I look forward to hearing from our I2S testers!

I2S on RP2350 working nice on all sample rates now.


I2S on RP2040 can not be selected in hardware output assignment... when i select i2s in combobox, it just resets to defaults after several seconds.
Also any parameter change can not be committed with error dialog: "Error Failed to save parameters". Tried flash_nuke.uf2, DSPi-Console 1.1.3 version from release, i've build DSPi-Console myself, but problem remains.

 

[JuanjoS]

I have just pushed DSPi Firmware v1.1.3-beta2, which fully addresses the buffer fill/drain issue at 44.1KHz. I look forward to hearing from our I2S testers!

Next, I am setting my sights on the USB descriptor bug. Manual driver installations via Zadig should be completely unnecessary.

Buffer at 44.1Khz fine Thanks

 

[mirkoseghezzi]

Welcome, and see the procedure here : https://www.audiosciencereview.com/...-less-than-a-cup-of-coffee.69343/post-2551562

Hi, thank you very much!

 

[Ajay]

Please find attached another schematic for a simple(ish) 2.1/Active_2.2 DSPi setup - I have included links to the various intellectual property I have pinched, in case anyone is interested. The one I found most useful was the st.com AN5073 as I did not realise the problems with using buffered inverters for SPDIF input. Unfortunately a lot of random circuits use standard 74HC04 which can cause 240MHz oscillation with low/no signal..... The PSU side depends on whether you need a 12V trigger out (some equipment is also okay with 5V) and you can reduce power consumption with DC-DC modules but ideally these need filters on the input to stop your cables acting as RF transmitters - i.e. more cost and complication.

I've tried to stick to sensible Pico pins this time, so it will probably be okay if I haven't fecked anything up - the magic is in the software, as always. I can't imagine they'll be useful at this stage, but if anyone wants the Kicad project files, let me know. ONLY the schematics, no PCB layouts will be done until the software features are fixed, if ever!

 

[Red_Red]

Please find attached another schematic for a simple(ish) 2.1/Active_2.2 DSPi setup - I have included links to the various intellectual property I have pinched, in case anyone is interested. The one I found most useful was the st.com AN5073 as I did not realise the problems with using buffered inverters for SPDIF input. Unfortunately a lot of random circuits use standard 74HC04 which can cause 240MHz oscillation with low/no signal..... The PSU side depends on whether you need a 12V trigger out (some equipment is also okay with 5V) and you can reduce power consumption with DC-DC modules but ideally these need filters on the input to stop your cables acting as RF transmitters - i.e. more cost and complication.

I've tried to stick to sensible Pico pins this time, so it will probably be okay if I haven't fecked anything up - the magic is in the software, as always. I can't imagine they'll be useful at this stage, but if anyone wants the Kicad project files, let me know. ONLY the schematics, no PCB layouts will be done until the software features are fixed, if ever!

Another nice suggestion (though less ambitious than the first).

Is there a reason for your choice of SPDIF coaxial RCA rather than optical Toslink? Because, in theory, with TTL Toslink transmitters and receivers like the FCR684214T (or R), you would greatly simplify the number of components needed and avoid potential ground loop problems and RF interference.

However, I do note the implementation of the rotary screen/encoder/IR receiver... although for that, support would obviously need to be pre-programmed in the firmware...

 

[Ajay]

Is there a reason for your choice of SPDIF coaxial RCA rather than optical Toslink?

Two reasons really, 1) it's easier to breadboard an inverter input and 2) no default kicad Toslink symbols + I'm lazy. You're right that it would be the preferred option - I don't know how many DACs/Amplifiers have only Coaxial SPDIF input? I mean, Coax can be isolated as well but at a cost. I guess it will depend on what hardware, if any, Troy plans to offer for purchase. Additional Also; for some reason the majority of (cheap?) Toslink receivers seem to be 5V, which is a problem for the 3.3V Pico.

So far as firmware support for screen/encoder/remote/etc. all we would need would be for Troy to expose some functions and variables that are "safe" for the DIYers to play with. It should be fairly trivial to support additional hardware, but obviously it will depend on what resources are available when it's running under the expected load.

It might be easier for Troy to expose a UART and a series of commands (a simplified version of the USB command set?) that way he can keep control of the resources and avoid anything nasty that can happen if you try and shove some random code in the middle of an intricate program. Then anyone can connect another processor of any type and use that for control - this is the approach I would prefer as it avoids doodling on the Mona Lisa. I'm not exactly sure where this project is heading, but as long as it's open source, someone will create a fork and add some unnecessary extra bits.

P.S I'm just playing!

 

[Weeb Labs]

I2S on RP2040 can not be selected in hardware output assignment... when i select i2s in combobox, it just resets to defaults after several seconds.
Also any parameter change can not be committed with error dialog: "Error Failed to save parameters". Tried flash_nuke.uf2, DSPi-Console 1.1.3 version from release, i've build DSPi-Console myself, but problem remains.

I'm glad to hear that buffers are now behaving correctly for I2S output. I will be investigating the RP2040 issue this evening.

However, I do note the implementation of the rotary screen/encoder/IR receiver... although for that, support would obviously need to be pre-programmed in the firmware...

This will be implemented shortly in the same manner as the output slot selection. There will be a number of external control slots with a verb, noun and GPIO structure.

Here is a very early implementation of that UI.

 

[Ajay]

Here is a very early impelementation of that UI

Beautiful! Always one step ahead

 

[Red_Red]

Toslink receivers seem to be 5V, which is a problem for the 3.3V Pico.

Not the one I mentioned (FCR684214R). It accepts 3.3V (2.7 to 5.5V DC).

P.S I'm just playing!

Yes, but it's a healthy game !

 

[Ajay]

Not the one I mentioned (FCR684214R)

Yeah, I had a look at those but wasn't aware of them before - I usually use Mouser and they only had one or two 3.3V receivers at over £12 each. The really cheap ones direct from China seem to be 1% of that cost and inspire about as much confidence! I found the FCR684214R/T at Farnell for £3/£2 respectively which seems like a bargain.

I'm getting twitchy enough that I'm going to have buy a couple of Pico2s and various components, most of which I have locked away in storage, just to scratch that itch!

 

[somebodyelse]

Here is a very early implementation of that UI.

Presumably once it gets beyond a prototype the encoder inputs will assign 2 pins not one. Will it also use PIO for decoding quadrature, or have you used all of that?

 

[Weeb Labs]

Presumably once it gets beyond a prototype the encoder inputs will assign 2 pins not one. Will it also use PIO for decoding quadrature, or have you used all of that?

Yes, it will assign two pins. I may use one state machine to handle the sampling (avoids CPU interrupt latency) for multiple encoders but decoding will still be done in software. There are two state machines left on the RP2040 and five on the RP2350. If I handled decoding on the state machine, that would limit us to one encoder per state machine, which I believe to be wasteful.

 

[Kurt_]

Please find attached another schematic for a simple(ish) 2.1/Active_2.2 DSPi setup - I have included links to the various intellectual property I have pinched, in case anyone is interested. The one I found most useful was the st.com AN5073 as I did not realise the problems with using buffered inverters for SPDIF input. Unfortunately a lot of random circuits use standard 74HC04 which can cause 240MHz oscillation with low/no signal..... The PSU side depends on whether you need a 12V trigger out (some equipment is also okay with 5V) and you can reduce power consumption with DC-DC modules but ideally these need filters on the input to stop your cables acting as RF transmitters - i.e. more cost and complication.

I've tried to stick to sensible Pico pins this time, so it will probably be okay if I haven't fecked anything up - the magic is in the software, as always. I can't imagine they'll be useful at this stage, but if anyone wants the Kicad project files, let me know. ONLY the schematics, no PCB layouts will be done until the software features are fixed, if ever!

I found this PCB idea doing a Google search. No idea if the person responsible is using this forum.

https://github.com/Darren-project/custom_weeb_lab_SDPi_PCB?tab=readme-ov-file

Personally, I think it's a rather interesting solution.

 

[Salt]

I found this PCB idea doing a Google search. No idea if the person responsible is using this forum.

https://github.com/Darren-project/custom_weeb_lab_SDPi_PCB?tab=readme-ov-file

Personally, I think it's a rather interesting solution.

The github folders are over 2 month old, this thread started on Feb 5, so ... intersting