SPDIF input

Status
Not open for further replies.

Frank B

Senior Member
Hi,

I wonder how a SPDIF input could be realized.
Spdif uses a self-clocking code, called "biphase mark encoding", a variant of the manchester code.
The challenge (i think!) is a) to reconstruct the clocksignal from the bitstream, b) to detect the frame-markers ("Preambles")

a): I think there must exists well-known techniques to do this. I do not know them :)
So.. how does this work ?
Is it possible with a few gates in hardware ? Perhaps some 74xxx ? or a PLL (74HC/HCT4046??) ? It should be as simple as possible.
I'm not that expirenced with electronics..but i like challenges :) And i'm willing to learn.

Maybe b) could be done with the i2s-device inside the Teensy if we have a clock.
 
Last edited:
I think i have found a way with timer capture.
Unfortutantely i have to setup some hardware first before i can code it.

But..let me ask... Is anyone interested in spdif-in ?
If yes i 'll put it to the top of my private hobby todo :)
But i dont want to do the work if nobody is interested.

The solution will need NO external HW except the required interface. It will occupy some cpu-power too...
 
I think i have found a way with timer capture.
Unfortutantely i have to setup some hardware first before i can code it.

But..let me ask... Is anyone interested in spdif-in ?
If yes i 'll put it to the top of my private hobby todo :)
But i dont want to do the work if nobody is interested.

The solution will need NO external HW except the required interface. It will occupy some cpu-power too...

Where can i buy a TOSLINK-Receiver ? TORX147 seems to be ok, bu i can't find any distributor at the moment... they're on ebay, but
delivery would be mid-august (shipping from china) :-(
 
Last edited:
But..let me ask... Is anyone interested in spdif-in ?

i did get curious at least ... that said, i'm fairly innocent when it comes to S/PDIF, so i was mainly wondering about possible use cases. IIRC the audio socket on mac books double up as S/PDIF out, so i was wondering whether, in the absence of usb audio, this would might be a way to have audio applications (running on a computer) interface with teensy + codec. or would this interfere with the i2s stuff? in which case a SPI DAC might work? somewhat like this: http://expert-sleepers.co.uk/es4.html
 
i did get curious at least ... that said, i'm fairly innocent when it comes to S/PDIF, so i was mainly wondering about possible use cases.

Ideally, there should be an input for the AudioLibrary, like the others. It could be used for digital effects, for example.

I don't know if this is possible - may be this input takes too much CPU load.
Perhaps the next gen Teensy...

The I2S will still be usable. My idea was to setup the timer hardware to measure the time between signal edges and transfer them to a buffer via DMA ( I think the timer can do all this automatically, in hardware).
A simple loop (in isr, called when the buffer is half full) translates this stream to samples. Eventually, we can jump over some of the bits (add their values with the dsp-extensions?) to save some CPU load, because we need only 16 in every subframe.
It is insensitive to jitter, by the way.

The cpu-usage will be high, (perhaps too high for the T3.1 to do anything useful with this data - so maybe i was bit too enthuiastic). But i think there is a chance....
 
Last edited:
This might be faster than the DMA engine can process events. Even though the DMA is incredibly fast when transferring data, it requires many cycles to respond to an event. After the event, many more cycles are used to update the transfer descriptor, before it can respond to another event.

The fast peripherals like I2S have small FIFOs, so the DMA engine can move several words with a single event.

Unfortunately, the timer input capture doesn't have a FIFO or even double buffering. Aren't the rising edges only 177 ns apart when biphase mark encoding transmits a "1"? Even at 120 MHz overclock, that's only about 21 cycles per event. I'm pretty sure the entire DMA response process needs more than 21 cycles. When/if we get a 180 MHz part, perhaps the DMA could just barely keep up?
 
This might be faster than the DMA engine can process events. Even though the DMA is incredibly fast when transferring data, it requires many cycles to respond to an event. After the event, many more cycles are used to update the transfer descriptor, before it can respond to another event.

The fast peripherals like I2S have small FIFOs, so the DMA engine can move several words with a single event.

Unfortunately, the timer input capture doesn't have a FIFO or even double buffering. Aren't the rising edges only 177 ns apart when biphase mark encoding transmits a "1"? Even at 120 MHz overclock, that's only about 21 cycles per event. I'm pretty sure the entire DMA response process needs more than 21 cycles. When/if we get a 180 MHz part, perhaps the DMA could just barely keep up?

Oh.. thats a new information.
I did not know that there is a latency with DMA.
Where can i read more about it ?
 
Look in section 21.4.4.2 "Peak request rates" in the reference manual.

It seems the performance is better than I thought. Maybe it can work at 96 or 120 MHz? Maybe....
 
That looks feasible. I want to try, at least, how much power is really needed to decode SPDIF, and which optimizations are possible.
 
Frank, Any luck with this yet?

What about an initial CPU-intensive loop in which to calculate the clock source of the SPDIF by measuring the edges of the input signal and then setup an internal I2S clock for continuous reading (in a similar way as your SPDIF output implementation works)? Or will such a implementation have some error frames once in a while? I know an external board with for example a WM8804 would be the best option to go with, but it would be great to do it with a Teensy stand-alone!

My goal is to use the Teensy as a sample-rate converter for at least one SPDIF input to a TOSLINK ADAT Output. That ADAT Output I managed to get working already ;) Don't know if a free C++ samplerate converter is feasible on the Teensy (maybe the Teensy doesn't have enough power to do sample rate conversion)... That's one thing for me to find out soon...
 
I think that a special IC with an integrated PLL to regenerate the clock is more efficient than to violate the Teensy to act as a DPLL.
 
Status
Not open for further replies.
Back
Top