The Raspberry Pi and Teensy 3 both have I2S interfaces, and that means these boards can be used to play very high quality audio. A codec and an I2S interface is one thing, but turning that digital stream into a quality analog output is another thing entirely. You need only look at audiophile forums for enough mis- and disinformation for that evidence.
For his Hackaday Prize entry [William Hollender] is building an audio board for the Teensy 3.x. It features very high-end opamps, the right filters, and the correct topology to turn a digital audio stream into an analog signal that would please the most temperamental ear.
The Teensy Super Audio Board uses the Cirrus CS4272 audio codec chip, a high quality chip that can handle sample rates of up to 192kHz at 24 bit depth. This chip doesn’t include the analog input and output buffers, and this means [William] has quite a build in front of him. This means using high quality opamps, low noise power supplies, and knowing how to build a circuit and measure its noise.
So far, the tests revealed incredible dynamic range, flatness, and frequency response of this tiny little board. It also works with the Raspberry Pi. Now it’s just a matter of getting a few more of these boards put together for the Best Product part of the Hackaday Prize.
“Sounds good” for once. Hearing impaired has been the goal of every engineer since before Carlheinz Brandenburg. It’s about time, I love progress!
Whenever I see two images side by side, I look in 3D crosseye just in case it really is. Nope. But I did see that cap in the right upper corner. Pluto in 3D? I saw it!
There are two options with high quality audio. The first is to convert the I2S to audio yourself, trying to keep noise and distortion to a minimum.
The other method? Convert to SPDIF (optical has great isolation, avoiding ground loops) and combine with a good amp.
Since the result probably gets fed into an amp anyway, the second method would be easier to implement. Kudos to [William] for going the lesser trod path.
S/PDIF’s big weakness is the clock – it is embedded in the signal and varies as appropriate with the sample rate. Most cheap DACs simply extract the clock and use it to drive the conversion. Thus, your S/PDIF source provides the clock for conversion, and it may have significant jitter in it. Proper DACs buffer the data and regenerate the clock from a better internal source. But that adds to their cost.
From what I’ve been reading, USB DACs are better than S/PDIF ones, at least at the affordable end of the spectrum.
Sony, Yamaha etc. make home theatre amps. These usually have inputs of (1) analog RCA, (2) SPDIF, and lately (3) HDMI. The idea of a DIY DAC may appeal to some purists. Me? I’d settle for getting the signal into the amp.
agreed. spdif is THE format (right now) for box-to-box comms on digital audio. hdmi is a hack; its full of DRM and does not even exist, afaiac. hdmi can go suck eggs; for audio I use spdif.
i2s is very touchy and even inside a box its hard to do right. clock edges have insane risetime specs. timing IS determined by one of the clock edges (usually its master clock but it could be wordclock, depending on dac). some companies have used rj45 and even hdmi connectors to ship i2s across boxes. its not a good idea. you gain nothing good by sending local protocols remotely.
spdif has clocking built-in and that’s bad, but clocks can be recovered by any decent (wofson comes to mind) spdif receiver chip with a fifo.
also, usb audio is becoming the new audio connect. UAC2 (asynch) solves all the problems of spdif and also allows dsd data to be sent (even multichannel) and since usb is dual direction, you can control and query devices instead of just pushing data TO them.
finally, there are new standards that we may see in home audio. audio over ethernet (ip) is coming along and while its still studio and pro use only, it WILL make its way into home audio, no doubt about that. usb2 uac2 will be around during the transition but longer-term, I see ethernet and ip being the main connect going forward.
i2s is something to be used for a few inches, on controlled impedance boards. if you ship i2s over wires, you have already failed to understand what its purpose really was and what its strong points were.
One really nice feature of S/PDIF is optical or transform-coupled isolation. Ethernet has that too, but USB doesn’t.
Williams’s board uses isolation chips for the I2S data and I2C control signals. :-)
There may be some rare cases where you have no need for isolation, but they almost never involve a microcontroller or Linux-based board. When you’re doing something interesting enough to need a board like Teensy or Raspberry Pi, you’re almost certainly connecting it to other stuff. At 16 bits resolution, and especially at more than 16 bits, even the slightest ground loop currents will contribute more than 1 LSB noise, and usually *much* more.
In fact, if you’re looking for audiophile grade performance, perhaps even isolation with high capacitive coupling should be considered as a possible noise source.
Two options?
You forgot about vacuum tubes hand made by a old Japanese craftsman living in the mountains of Honshu, who uses only tube operated equipment running on solar panels and his own golden ear to test them. B^)
And I thought they were left handed dwarfs who only fabricate during the full moon in the Brazilian rain forest, I stand corrected.
they were the guys who made Gundams
@Alan
I’m not an audio guy. Could you explain why optical not conducting and thus not supporting a ground loop is relevant for the digital leg of a digital-to-analog converter? I’d have thought needing a power source makes a DAC as susceptible to ground loops as if it were connected via some electrical conductor.
If needing a power supply necessarily made any analog signal susceptible to ground loops, then high quality audio amplifier & receivers could not exist. Very good quality audio receivers and amps, with DAC inputs, do of course have very substantial power supplies inside!
Ground loops are (usually) formed when equipment with two *different* power supplies are connected together with a common ground. Any ground current, even very small, which isn’t a perfect balance to the current flowing due to the actual signal, can induce non-signal voltages with add noise to analog signal.
It’s easy to think of digital audio as pure ones and zeros, impervious to analog effects. It’s easy to think that ground loops are irrelevant if the communication is all digital. Indeed, the digital bits are communicated with enough noise margin to resist such trouble. But if the data is to be converted to an analog signal at some point, so it can be heard by humans, the digital-only connection can create ground loop currents which impact the later conversion to analog.
That’s why isolation is relevant for digital-only audio data. Ultimately it has to become analog if it’s to be heard. Ground loops are the dire enemy of quality audio!
What’s the general state of I2S support in the linux kernel? Did OP need write something that converts alsa buffers to I2S-compatible bitstreams and then write a driver that takes these bitstreams and pushes them out to the I2S peripheral? Or does Linux offer a general I2S layer, where you’d only have to implement a few functions to do the actual work?
I wrote a reply but accidentally made it a general article reply rather than one to your comment specifically. See below (or maybe above, I don’t really know what the order is based on).
There is an I2S layer available in Linux. This implementation (and other RPi devices) use the ALSA System-on-Chip driver system which has separate driver modules for the host (the RPi’s BCOM SoC in this case), the codec or dac (the CS4272 in this case), and a system level driver that ties everything together.
I was lucky because the host driver, and a compatible codec driver (for the CS4271) already existed, so all I had to do was put together the system level driver and device tree stuff to support it. I’ve never done any kernel development before, so that was plenty for me :)
Teensy doesn’t run linux. Raspberry Pi does but I believe that the libraries/drivers necessary to use the I2S for audio on the RPi have already been written, as this is not the first RPi-compatible audio board that uses I2S (e.g. HifiBerry, RPI-DAC and RaspyPlay).
Oops, this was supposed to be a reply to AK47RFa.