Electronics project notes/Audio notes - Digital sound communication
| This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, or tell me) |
This is mostly about hardware interconnects. For software media routing, see Local and network media routing notes
Typically external
S/PDIF
S/PDIF ("Sony/Philips Digital Interface") (a.k.a. IEC958) is purely the protocol, not a connector.
...but S/PDIF is often carried over either
- fiber, typically used with TOSLINK connectors
- a single RCA connector on (preferably) a coaxial cable
S/PDIF tends to carry either
- raw PCM
- surround (compressed, because of bandwidth limitations), often either:
- DTS for 5.1/7.1 -- more specifically the DTS Coherent Acoustics (DCA) codec
- AC3 (Dolby Surround)
See also:
Not to be confused with
- AES/EBU (next section)
AES3
| This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, or tell me) |
AES3, also marked AES/EBU, is a digital audio protocol very comparable to S/PDIF - the data format is actually largely the same,
yet not qutie compatible.
ADAT
| This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, or tell me) |
ADAT has referred to two distinct things
Historically, and now rarely, to the Alesis Digital Audio Tape, a way of storing eight tracks digitally onto Super VHS
And much more typically to the ADAT Optical Interface, more commonly known as ADAT Lightpipe or often just ADAT, also from Alesis.
It looks the same as TOSLINK / S/PDIF, but speaks a different protocol, and somewhat faster.
It carries audio channels that are always 24 bit (devices that are 16-bit will effectively just use the 16 highest bits).
Its speed lets it carry
- up to eight channels of those at 48kHz.
Or, with the common S/MUX extension
- up to four channels at 96kHz
- up to to two channels at 192kHz
See also:
Typically internal
I2S
| This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, or tell me) |
(Note: no technical relation to I2C)
I2S (sometmimes IIS), Inter-IC Sound is meant to standardize PCM data between closeby chips.
It separates clock and data, means it can have lower jitter (and indirectly latency) than buses that don't.
As I2S doesn't spec a plug, or how to deal with longer cables (impedance and such), it is indeed mostly used within devices.
Exceptions mainly being audiophile setups that want to choose their DACs. Because it wasn't made for that, this takes more care to do right, because impedance can cause synchronization issues, particularly at higher bitrates.
Lines and bits and interpretation
The lines are
- bit clock (BCLK) (a.k.a. continuous serial clock (SCK))
- left-right clock (LRCLK) (a.k.a. word clock, word select (WS), Frame sync (FS))
- data
- ground
BCLK pulses for each bit, so should be samplerate * bitdepth * channelamount, e.g. 1411200 Hz for CD audio (44100*16*2).
LRCLK selects left/right channel
Some also add a master clock (MCLK). This is not part of standard I2S
Note that:
- The protocol is fundamentally 2-channel (in part due to LRCLK's function)
- If you functionally want to send mono, you could send zero on the other.
- but if you have that sample anyway, then it makes just as much sense to output it twice, i.e. in both channels, so that if a receiver decides to implement mono by picking one channel, it doesn't matter which one.
- Sample rate is not configured, it is implicit from the sending speed(verify),
- which is part of why software bit-banging I2S would probably never sound great
- Bit depth is implied by when LRCLK switches (which it can do because the MSB goes first)
- with some work left to the receiver
DIY abuse
Because I2S interfaces are fairly high-speed, and typically DMA-assisted, it has found other uses.
Because channels=2, sample rate is controlled by the clock, and bit depth is somewhat implied,
you can vary some aspects of what it sends without negotiating it.
For example, when feeding in data into an I2S DAC, you do need to do the stereo interlacing as in the spec, and the bit depth as the DAC expects, but it doesn't need know the sample rate - it will do what you ask of it, at the rate you ask it to.
For example, the ESP8266 and ESP32's I2S is actually run from a more generic piece of hardware, roughly a glorified shift register, used to implement I2S as well as LCD and camera peripherals.
It happens to go at ~1.4MHz for audio, probably from a configured, but if you can control the output rate, then you can produce other sorts of signals, and DIYers have found it's fairly stable at 40MHz, which makes it possible to produce NTSC and VGA signals, and could even sample data at that rate.
Similarly, RP2040 has a Programmable I/O (PIO)[1] [2] [3]
You could probably send PDM over these - which would be an ironic use of something already intended for audio, but which might makes sense if the receiving side isn't an I2S DAC(verify).
See also:
- https://web.archive.org/web/20140223115501/http://www.eng.auburn.edu/~nelson/courses/elec5260_6260/Inter-IC%20Sound%20%28I2S%29%20Bus2.pdf
- https://web.archive.org/web/20080706121949/http://www.nxp.com/acrobat_download/various/I2SBUS.pdf
