elehobica/pico_spdif_rx

SPDIF receiver library for Raspberry Pi Pico

Raspberry Pi Pico spdif_rx

Overview

• SPDIF receiver by rp2040 PIO function
• format: 2ch, 16bit or 24bit
• sampling frequency: 44.1 KHz, 48.0 KHz, 88.2 KHz, 96.0 KHz, 176.4 KHz, 192.0 KHz
• signal detecting function for all supported sampling frequencies

Supported Board and Peripheral Devices

• Raspberry Pi Pico (rp2040)
• SPDIF Coaxial or TOSLINK Rx module (DLR1160 or equivalent)

Pin Assignment & Connection

SPDIF Rx

Pico Pin #	GPIO	Function	Connection
20	GP15	DATA	from SPDIF data

Notes:

• 74HC04 should be genuine device, otherwise (counterfeit device) it could not work at higher sampling frequencies.
• if TOSLINK only, direct connection from module output to GP15 will work as well.

How to build

• See "Getting started with Raspberry Pi Pico"
• Put "pico-sdk", "pico-examples" and "pico-extras" on the same level with this project folder.
• Set environmental variables for PICO_SDK_PATH, PICO_EXTRAS_PATH
• Build is confirmed in Developer Command Prompt for VS 2022 and Visual Studio Code on Windows enviroment
• Confirmed with Pico SDK 1.5.1, cmake-3.27.2-windows-x86_64 and gcc-arm-none-eabi-10.3-2021.10-win32

> git clone -b 1.5.1 https://github.com/raspberrypi/pico-sdk.git
> cd pico-sdk
> git submodule update -i
> cd ..
> git clone -b sdk-1.5.1 https://github.com/raspberrypi/pico-examples.git
>
> git clone -b sdk-1.5.1 https://github.com/raspberrypi/pico-extras.git
> 
> git clone -b main https://github.com/elehobica/pico_spdif_rx.git

• Lanuch "Developer Command Prompt for VS 2022"

> cd pico_spdif_rx
> cd samples/xxxxx  # sample project directory
> mkdir build
> cd build
> cmake -G "NMake Makefiles" ..
> nmake

• Put "pico_spdif_rx.uf2" on RPI-RP2 drive

Decode output format

• 32bit output for each SPDIF sub frame including header, audio data, AUX, VUCP
• see comments in spdif_rx.pio for further detail

Sample projects

detect_samp_freq

• display sampling frequency, C bits of SPDIF frame and number of parity errors while decoding

spdif_to_i2s_32b

• convert SPDIF input to I2S 32bit output

pico_spdif_rx's Issues

I2S slave output

Hi again!

I have been bothering you a lot on this repository already, there is still one thing I am wondering.
I have been trying to play with combining code from your pico_spdif_rx and malacalypses rp2040_i2s_example (https://github.com/malacalypse/rp2040_i2s_example) to create a spdif to i2s slave output. However, I have again pushed myself into a corner and none of the things I have tried are working.

Do you have any pointers for me to proceed on converting the project to allow I2S slave output, or is this a very challenging task to get spdif and i2s output synced if the pico is not acting as a master? While I have started learning pio, it is still very cryptic for me.
I had the I2S example working before with a PCM5102, but would like to change to my ADAU1701 board for the DSP functionalities and this requires for me to use the ADAU1701 as a master.

Any help would be greatly appreciated. Or if this is not something you are not interested in pursuing, I will slowly learn and commit to figuring it out by myself.

Best,
Miro

USB Sound card example?

I need to capture a 20-bit 44.1khz SPDIF stream and stream it to my PC. Is there an example of this being used as a USB Audio Input device anywhere?

Feature request

Hello,

Thanks for this very exciting project.
Do you have any plans, in the near future, to port this to RPi Zero 2 W also?

Also, an HDMI ARC Transmitter and Receiver using the RPi would be most welcome.
It would need an external HDMI connector with pin-14,19 giving us HEAC+ and HEAC- respectively, pin-18 connected to +5V through an 82E resistor and of-course we all the existing GND pins connected to GND. This will form the hardware interface.

2 Raspberry Pico W(ifi) one for SPDIF RX one for SPDIF TX

Hi,
Not an Issue but a project in my head which bothers me for quiet some time, but don't really now how to get there...

I'd like to build an endless SPDIF Extension cord via two wifi enabled RP2040 W Boards, So theoreically you could connect two spdif devices (source and target) anywhere in the house or even the world.

Your github page gave me sone hints, but nevertheless, I am kinda stuck on the Idea but have no idea how to make it work - and if it is able to work at all - When there is too much jitter on a wifi link to beginn with, that would not work at all, I think...

Do you have any thoughts or hints about this topic?

Would be a absolutely cool if that worked simply by a UDP Port where the receiving Pico fires the data, the receiver buffers it and spits it out to its SPDIF TX. - But is that too simple to work?

Cheers

assertion "!shared_state.playing_buffer0" failed

Hi!

First of all, thanks for the great work on this library. It makes yet another brilliant use case for rp2040.

I have successfully created the hardware to test your code out and managed to get the sample rate from my TV optical output to be recognized correctly with the detect sample rate example.

However, when trying the I2S output example, I get the following error:

Samp Freq = 48000 Hz (48.0015 KHz)
SPDIF C bits = 0x02000c04
Connecting PIO I2S audio
setting PIO freq for target sampling freq = 48000 Hz
System clock at 125000000 Hz, I2S clock divider 5208/256: PIO freq 6144393.0000 Hz
Copying stereo to stereo at 48000 Hz
Enabling PIO I2S audio (on core 0)
assertion "!shared_state.playing_buffer0" failed: file "/Users/user/pico/pico-examples/pico_spdif_rx/samples/lib/my_pico_audio_i2s/audio_i2s.c", line 548, function: audio_start_dma_transfer

I have no clue where to start looking for the solution for this problem. Any suggestions?

faster lock, etc

No issue, just abusing this for discussion / kicking ideas. Or is there another forum?

First, let me marvel your code contribution. Pico was definitely missing this. I've been loosely considering myself writing an S/PDIF input, but it would have been my first Pico let alone PIO project. Looking at the complexity of yours, a recipe for failure. I still need to understand the PIO code and the sync mechanism. The things I looked at are rather two-pass, first capture 2 bits or duration, then work out the sync and decode. I still lack to understand how you got away with single pass, having the payload directly available, and still detect the biphase violations for sync. (More documentation appreciated.)
Here was some discussion: https://forums.raspberrypi.com/viewtopic.php?t=318134

About the idea part:

The current code takes quite a while to sync, trying all sample rates and polarities. (BTW, what time to give per sample rate?) How about having something dedicated for the detection? First, measuring the frequency (if any) of some kind of software PLL/FFT/shortest pulses can give a quick sample rate guess. Not sure about detecting the polarity. Sync has 3 steady bits, but depending on previous bit they can have any polarity?

Edit: Perhaps different PIO code per sample rate is not necessary, if clocked slower by a factor of 2/4? Each state machine even has a fractional divider, so could be fine-tuned.

Edit2: I think the 2nd PIO code for the inverted variant is not necessary, if the input pin polarity can be changed by GPIO setting.

Less latency than a full block of 192 samples would be nice for realtime applications. With 44kHz, that's already >4ms.

In general, if and what further plans do you have with this project? From the commit frequency, it is work in progress?

Accessing channel bytes

Hi again!
I have been tinkering with the code for a while now trying to access the bits from SPDIF signal that LG uses to communicate their TV volume as mentioned in this guide:
https://github.com/hifiberry/hifiberry-dsp/blob/master/doc/reverse-engineering-lg.md

However, as I am quite the novice with handling bytes and bits, I am not getting anywhere with my efforts. If it is not too much trouble, could you point me to the right way? So much I have found out that this the check_block() function is probably to one I need to modify to access the correct bytes?

This code is used to access some of the bytes, but I'm quite not sure how it works and which bytes it is accessing?

// VUCP handling
// C bits (heading 32bit only)
if (i % 2 == 0 && cbit_mask) { // using even sub frame of heading 32 frames of each block
	if (buff[i] & (0x1<<30)) {
		block_cbits |= cbit_mask;
	}
	cbit_mask <<= 1; // will become 0 after 32 bits are collected, and stop the if()
 }

Best regards,
Miro