S/pdif

Status
Not open for further replies.
Wow..

Let me say, everything was already on the Internet - i've only put the pieces together :)
KPC code was really very helpful (and it helped me to get a better understanding), and without your existing code for the I2S output I would not make it.
I found other Ideas on the internet, esp. some tricks (i.e. the constant parity) came from a forum. The whole thing was done for other MCUs before (KPC posted a picture with the LED).
 
Last edited:
Let's swap, I send you one of my memoryboards (well, after i have done more tests, perhaps end of the week)
 
Sounds good. Can you email Robin directly (robin at pjrc dot com) with your current mailing address. She'll get it shipped out today! (or tomorrow if your message arrives after the postal lady picks up today's mail)
 
I don't know if it's worth implementing and a few more processorcycles:
Today i had the idea to use another lookup-table (would be 192 Bytes) for the Channelstatus (all VUCP-Bits to be correct). This would allow to disable the copyright-flag.

What do you think ?
 
I 'd be curious what is the jitter . Can you measure , Paul (or someone else) ? I believe it is sufficient to measure the BitClock.
I do not have the necessary instruments.

Then, i don't understand that some people say that the jitter with the TOSLINK is higer than RCA ?
I would expect the opposite (No transformer and other circuitry, no cable where the signal gets influenced by other electric fields).
 
Last edited:
Too much components ? Want less ? :)

It works even without external components. A single wire is sufficient:

LED_TOSLINK3.jpg

LED_TOSLINK4.jpg
 
PaulStoffregen said:
Sounds good. Can you email Robin directly (robin at pjrc dot com) with your current mailing address. She'll get it shipped out today! (or tomorrow if your message arrives after the postal lady picks up today's mail)
Click to expand...

Hm, something must gone wrong.
I think it's lost somewhere between US and Europe...
 
I had to implement software SPDIF encoding and looked at this code. It seems to me a bit hard to understand and somewhat more convoluted than necessary. A three uint32_t[256] table approach would be faster (at the expense of 6x table storage), not need byte displacement and generate parity in the right place. My proof of concept uses ~7% CPU encoding 48KHz stereo on a STM32F072 running at 49.152MHz. Let me know if you're interested in the details.
 
Just found the teensy audio projects and I've already started ordering bits for my DIY audio system :)

Question though, there is a lot of info about digital output but is there any way of taking a digital input and decoding it with the teensy? I'd love to use S/PDIF input with two audio boards for output
 
Anyone interested in adat? I have a dream of low latency piezo/other sensors to adat plugged to an expert sleepers es-3 to control a modular... 8 D.C. Coupled outputs at 10vpp.

Seems like the protocol has been reverse engineered, https://ackspace.nl/wiki/ADAT_project

Wondering if anyone has coded or thought about it.
 
bafonso said:
Anyone interested in adat? I have a dream of low latency piezo/other sensors to adat plugged to an expert sleepers es-3 to control a modular... 8 D.C. Coupled outputs at 10vpp.

Seems like the protocol has been reverse engineered, https://ackspace.nl/wiki/ADAT_project

Wondering if anyone has coded or thought about it.
Click to expand...

Yep, I am quite new to Teensy and this kept me busy the whole weekend. But so far without success. I don't know whether this is doable, because of the usage of NRZI of the whole frame, which costs a bit more processing power than the Biphase mark encoding used in the SPDIF implementation. Also the bitrate is twice as high... Have you tried to get it working?
 
PaulStoffregen said:
Awesome! Would it be ok to merge this back into the audio library?
Click to expand...

Sure! I would be honored!

Perhaps some clock settings changes are necessary to make it compatible with the rest of the audio library. I've tested with the internal 44117Hz of the Teensy audio library and my 01V96 understands the signal, but I don't know if it violates the ADAT specs or if other devices have problems with such a signal... I could test other devices though (I also have some ADAT-compatible MOTU devices)...
 
Looks good! I've tested the beta 1.41 teensyduino version and it worked :) I would be interested in some CPU load information though...
 
Ej@Y said:
I would be interested in some CPU load information though...
Click to expand...

For the portion that runs from the low priority audio interrupt, you can query the CPU usage.

https://www.pjrc.com/teensy/td_libs_AudioProcessorUsage.html

For the hardware interrupt that runs at higher priority, the best way to measure involves adding digitalWriteFast at the start and end of the interrupt. Then you can use a DC voltmeter or oscilloscope to measure how much of the time it's high vs low. Almost all DC multimeters will properly show the average of a pulsing signal, but if you're really concerned and don't have a scope, you can RC lowpass filter the signal to get a nice DC signal.
 
Would the Everlight <PLT133/T8> work for you instead ?? It is available in single quantities for $1.41 from Mouser Electronics (in-stock) & DigiKey (20-week lead-time).

Mark J Culross
KD5RXT
 
Mark - thanks for the response. Not sure how I missed that one, but looks like it's perfect.
thanks again!

Dana
 
Status
Not open for further replies.
Back
Top