[Beth] had the idea for transmitting digital audio over S/PDIF on a Propeller a few years ago, but only just got around to a writeup. For that, we thank her.
The writeup has a marvelous walkthrough of the S/PDIF protocol and the problems associated with with generating the signal. S/PDIF is a relatively resource-intensive protocol – the signal is clocked at 64x the audio sample rate. That signal is doubled for biphase mark code, keeping everything in sync. [Beth] says the microcontroller would neet at least 24 MIPS of processing power just to generate the S/PDIF signal – processing audio would be another task altogether. Because of the processing power needed, and the weird clock rates needed, [Beth] decided to go with the Propeller. The implementation uses only one core of the Propeller, leaving another seven cores available for sound synthesis or even a visualization over VGA.
[Beth] admits this could be done with just about any microcontroller (although it would need to be clocked at a multiple of 4.096 MHz for a 32kHz audio stream), but we really appreciate the work that went into bit-banging this signal.
Video of [Nick] at Gadget Gangster playing around with digital audio on a Propeller after the break.
[vimeo http://vimeo.com/19992819%5D
Dzihan and Kamien, the man has taste ;)
Doesnt this need a laser diode to work properly?
Any light source that can be switched on or off fast enough will work fine. Typical home audio interconnects are non-coherent, meaning cheap light sources and cheap optical cables.
it’s neat that the encoding of the protocol is so complex and esoteric, but the physical layer is just a single SMD LED.
This makes me want to convert a handheld or studio microphone to optical SP/DIF. Probably something wireless, since it’ll have power built in. It would be great for field recording in hostile environments, where you have to run cabling through seawater or mud or across a pool.
Aren’t their chips that are designed to do s/pdif?
There are certainly small devices – portable a/d’s and recorders – that output and accept s/spif.
SP/DIF is a braindead simple protocol, but it’s not something that lends itself to bitbangery. If your micro has a buffered and decently configured SPI interface you’re better off doing I2S and using an external converter. Using a micro to generate it directly insures you’re going to introduce jitter into the signal and add distortion to the audio unless it’s reclocked.
Distortion is an analog concept. With a digital protocol either the data gets there or it doesn’t. A little jitter won’t hurt a thing, a lot of jitter corrupts the data.
Not true, I’m afraid. It’s not about whether the data gets there or not, it’s about how it’s reproduced from that point on. A lot of cheap and nasty reproduction systems recover clock from S/PDIF and use it to directly drive a DAC. Clock recovery from a clock-embedded signal is prone to all kinds of distortions, and any jitter will only make it worse. Then there’s possible SRC at the receiving end – S/PDIF has no fixed rates, so some receivers are designed to resample the data to a standard rate based on the instantaneous timing of the incoming signal.
Your statement applies only to buffered systems with full reclocking and proper isolation. Many many systems are not that well engineered.
My soundblaster AWE64 gold had spdif lol. We mainly used it back in the day to sync to video via in-house clock. Higher res than MTC and FSK at least back then. No tellin what you kids are into now ;)
SP/DIF is a self-clocking protocol – it doesn’t just matter that the data gets there, it also matters when exactly the data gets there. For fairly unavoidable reasons SP/DIF attached DACs generally derive their clock from the recovered clock of the SP/DIF link. If there’s jitter in the clock you get jitter in your DAC clock too and that leads to distortion of the analog audio.
S/PDIF even… apparently I copied the typo of the comment I was replying to.