It’s IP, Over TOSLINK!

At the recent 38C3 conference in Germany, someone gave a talk about sending TOSLINK digital audio over fiber optic networks rather than the very low-end short distance fibre you’ll find behind your CD player. This gave [Manawyrm] some ideas, so of course the IP-over TOSLINK network was born.

TOSLINK is in effect I2S digital audio as light, so it carries two 44.1 kilosamples per second 16-bit data streams over a synchronous serial connection. At 1544 Kbps, this is coincidentally about the same as a T1 leased line. The synchronous serial link of a TOSLINK connection is close enough to the High-Level Data Link Control, or HDLC, protocol used in some networking applications, and as luck would have it she had some experience in using PPP over HDLC. She could configure her software from that to use a pair of cheap USB sound cards with TOSLINK ports, and achieve a surprisingly respectable 1.47 Mbit/s.

We like this hack, though we can see it’s not entirely useful and we think few applications will be found for it. But she did it because it was there, and that’s the essence of this game. Now all that needs to happen is for someone to use it in conjunction with the original TOSLINK-over network fiber, for a network-over-TOSLINK-over-network abomination.

19 thoughts on “It’s IP, Over TOSLINK!

  1. Ok so now we have network over toslink. A week or so ago we had toslink over lasers to wirelessly control speakers and those lasers can travel longer distances.

    The only logical next step is wireless internet (point to point) over toslink.

  2. TOSLINK may find some actual useful use cases. Maybe you want to communicate with some device on top of a tesla coil…

    But TOSLINK is quite different from I2S. It’s the same data, but I2S uses three signals (Clock, Data, and L/R), while both TOSLINK and SPDIF use only a single channel in which the data is Manchester encoded.

    Also, 44.1kHz 16 bit is quite old, 24bit 96 kHz has about 4x the data rate and was also common. As was 7 or so channel surround sound, but that uses compressed data.

    1. It’s not even the same data – TOSLINK/SPDIF basically use the AES3 protocol, which wraps the audio data with control words/timecodes/etc, Manchester encodes it and sticks a (non-Manchester) preamble in front to handle frame boundary detection. I2S is just serialized audio data.

      Obviously if you just ignore the extra bits it’s the same audio data, but you can’t like, take I2S and Manchester encode it and get SPDIF or anything, you need smarts. Because of the low overall data rate I2S and SPDIF encoding/decoding examples in FPGAs are pretty common.

  3. One part of the project seems like the opening for a bigger and probably less whimsical bit of hackery. It notes:

    “Don’t buy sub-10$ sound cards.
    These cards have crashed my Linux kernels in several ways, including crashing the full XHCI USB host controller in a way that needed a reboot.”

    When that is how something reacts to a peripheral being incompetent; you can only brood darkly on how badly it would take a peripheral being malicious.

    1. Any OS would react the same when a kernel module is malicious or bugged. BYOVD (bring your own vulnerable driver) is a common attack on Windows, and while MacOS ecosystem is too locked to allow a random soundcard to work, it would do the same.

      Kernel mode is quite different than user mode. In user mode a crash takes down the app, in kernel mode the crash takes down a subsystem, or the entire system, because the module must have more access: a hardware driver module without hardware access is not very useful.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.