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

[Barrelhouse Solly]

Works fine for me. But please do explain your setup and if you did anything else, so Troy might be able to look into it.

I'm using the same setup I've used for several months. USB in to Pico. Toshiba TX179 transmitter out. GPIO 6 to pin 3, 5V to pin 2, and ground to pin 1. It works fine with v 1.1.4 but not with 1.1.5 and higher. I've tried it with different Picos, both 2350 and 2040. Same results with all. I'm using known good Dupont connectors.

 

[Weeb Labs]

I'm using the same setup I've used for several months. USB in to Pico. Toshiba TX179 transmitter out. GPIO 6 to pin 3, 5V to pin 2, and ground to pin 1. It works fine with v 1.1.4 but not with 1.1.5 and higher. I've tried it with different Picos, both 2350 and 2040. Same results with all. I'm using known good Dupont connectors.

It might be worth verifying that your output slot configuration isn't being reset under v1.1.5, as there are many flash changes between those revisons. If not, perhaps try reapplying the settings. Coaxial and TOSLINK both use the same initial 3.3V TTL output, so there's no real mechanism by which one could work but not the other unless they're on GPIOs that are assigned differently.

 

[Barrelhouse Solly]

TTL output is set to GPIO6 under both. I also have one of those PC expansion cards with TOSLINK and coax outputs. When I connect to it I only get output from the coax port. The TOSLINK port in either case doesn't light up. I'm not really inconvenienced because I can use either optical port on my DAC. It's more a matter of curiosity.

 

[BURNART]

Is there any way to add soft startup? When playing via usb there is no problem, but when I use ADC and connect 5v to freenova breakout board I've got a pop.
My ADC is like this:

 

[Weeb Labs]

Is there any way to add soft startup? When playing via usb there is no problem, but when I use ADC and connect 5v to freenova breakout board I've got a pop.
My ADC is like this:

If you are using a PCM5012A DAC, it should be possible to implement a soft startup using a high value pull-up resistor on it XSMT pin and configuring EMC. That should keep the DAC muted at startup and only unmute when the audio pipeline is ready.

In other news, I have been working on an Overview settings page for DSPi Console, which should enable users to see at a glance the active GPIOs.

 

[sam_adams]

Thank you very much for sharing!

To set up an IR remote control, you can use one of these inexpensive VS1838B receivers.

Wonderful job you are doing with this. There aren't enough accolades to express how grateful The Membership here feels.

On the subject of remotes, maybe you could look at FLIRC integration. Very popular in the Linux/Pi community. Links:

Universal remote

Amazon link

USB receiver

Amazon link

Once again, thank you for all the innovation and hard work.

 

[BURNART]

If you are using a PCM5012A DAC, it should be possible to implement a soft startup using a high value pull-up resistor on it XSMT pin and configuring EMC. That should keep the DAC muted at startup and only unmute when the audio pipeline is ready.

Thanks, is it possible to add software outputs mute with timer?

 

[Till]

How do you connect a rotary encoder? Are pull-up resistors needed?
Can anyone show a diagram?

 

[Tell]

How do you connect a rotary encoder? Are pull-up resistors needed?
Can anyone show a diagram?

If it's one of these you have it's quite easy. Ground to any GND pin on the Pico, VCC to 3.3V (though 5V should work on the RP2350 but not on the RP2040), and switch, output A and B to whatever GPIO pin you choose in the Control Surface .

 

[Wesseling Audio Lab]

With Bluetooth Pico can iphone or android phone control DSPi volume through BT while streaming is from a connected USB device

 

[jrosser]

On the subject of remotes, maybe you could look at FLIRC integration. Very popular in the Linux/Pi community. Links:

Do remember that the DSPi is based on a Pi Pico microcontroller, not the more fully featured Raspberry Pi that runs Linux. That means that the current setup is as a USB device that connects to an external USB host to receive/transmit audio and control data. It does not natively have another USB host port to connect a USB FLIRC receiver to.

 

[mike_008]

On the subject of remotes, maybe you could look at FLIRC integration. Very popular in the Linux/Pi community.

Original is LIRC (linux infrared remote control) without F and way older than Rpi:

LIRC - Linux Infrared Remote Control

LIRC - linux infrared remote control

www.lirc.org

 

[MCH]

Repurposed ir receptor and remote or new from Ali is the easiest and cheapest way with microcontrollers

 

[john61ct]

USB device that connects to an external USB host to receive/transmit audio and control data

But once configured, DSPi does not Require an active USB host - correct?

Much less in the signal chain, which can just be ADAT, S/PDIF etc, right?

Yes I realise USB is common, I'm just asking, in principle.

ESP32 can be a host, right?

 

[Kingsnake]

But once configured, DSPi does not Require an active USB host - correct?

Much less in the signal chain, which can just be ADAT, S/PDIF etc, right?

Yes I realise USB is common, I'm just asking, in principle.

ESP32 can be a host, right?

I have my ESP32-S3 set up as a digital audio player and full-control frontend via UART, using a 512GB microSD card for music storage.

It sends the digital audio to the DSPi using a single data wire connected to one of the DSPi’s GPIOs.

I tried I2S and it was a little sketchy for me, but I managed to get the ESP32 S/PDIF running very reliably. It’s currently limited to a maximum of 24-bit/48kHz.

Music can also be transferred over Wi-Fi using a web page hosted directly by the ESP32. Transfer speeds are limited to around 0.6Mbps, but that’s perfectly fine for my needs.

I’m still testing the S/PDIF build, but I’m hoping to push it out this weekend.

 

[Weeb Labs]

A little spoiler here. We now have support for all common I2C character displays within Control Surfaces.

Several display modes are available, along with customizable pages and new nouns enabling the active page's parameter to be adjusted. With regard to RAM and CPU utilization, this was essentially free.

 

[Mike123]

I am currently designing a board on which, in addition to RPi Pico 2, there will also be a microcontroller. His tasks included:
1. Working with an encoder with a button.
2. Working with an IR remote control.
3. Volume display.
4. Configuration via IIC of amplifier chips.
Every day the number of points decreases. This way, soon you won’t need a microcontroller at all

Oh, by the way, a question for Troy, when will users of the despicable Windows also have the opportunity to try the beta version?

 

[somebodyelse]

With Bluetooth Pico can iphone or android phone control DSPi volume through BT while streaming is from a connected USB device

Not yet. It probably depends on what resources BLE requires - see here where WiFi was ruled out due to resource usage.

 

[Red_Red]

Oh, by the way, a question for Troy, when will users of the despicable Windows also have the opportunity to try the beta version?

Yes, I told him that months ago - about that (good or bad) habit of maintaining parity between versions for different operating systems...
That said, it’s still a project in development, so it’s perfectly fair to accept that, until a certain milestone is reached, Troy can do whatever he likes!
At the same time, since everything is open-source - meaning anyone can adopt this firmware and console, or even develop a custom board tailored to their own needs - well, frankly, while impatience shows enthusiasm, one still needs to keep things in perspective. Here, patience is the price you pay for it being free (though you can always buy him a Ko-fi to support the project, even if that likely won't change the situation regarding version parity for the time being).

 

[Weeb Labs]

I expect to update the Windows version this evening. While I always aim to maintain feature parity between platforms, the testing cycle unfortunately means that there will typically exist a delay of several days between macOS and Windows updates.

This is mostly because macOS is where I perform all of the hardware testing and firmware development, so it tends to reach a satisfactory state before Windows. I sometimes have to revert or re-engineer functionality, which means twice the workload if both platforms have already been updated and need reworks.

That’s the rationale for the current update cycle.