Getting Hi-Fi sound from Raspberry Pi
The key software is RaspBMC, a media player package based on the XBMC Linux distribution.
Together they offer network media access, remote control, and a whole host of other features usually found only on multi-hundred pound sound systems.
There is only one snag: Raspberry Pi’s own analogue audio output is distinctly medium-Fi.
So, Electronics Weekly asked itself, how difficult would it be to design a piggy-back board to add a high-quality audio output to Raspberry Pi.
A little phoning around revealed that more than one chip company has been thinking along the same lines, and by coincidence Wim Lemmers, principal application engineer at NXP, recently acquired three Raspberry Pis for his lab on which to develop Linux drivers for one of the firm’s audio codec chips.
“I bought a few Raspberry Pis a few weeks ago,” said Lemmers. “Revision 2 of the hardware has an extra connector implemented that contains exactly the signals that I require: I2C and I2S.”
I2S is a serial bus specifically defined for communicating digital stereo.
“Using I2S, you can implement any audio codec you like, but it has limitations: I2S can only be used for stereo,” said Lemmers.
Along with a ground connection, it has four wires: audio data in, audio data out, words select, and clock.
There is no data buffering. Audio data in and out are continuous strings of bits, directed and clocked by the other two signals.
For 16bit stereo from a CD (CDs are sampled at 44.1kHz), for example, the clock runs at 16x2x44,100=1.4112MHz.
Word select, in this case, carries an 44.1kHz square wave which indicates whether left or right channel data is being sent at any moment.
I2S is a sub-set of related time division multiplexed (TDM) pulse code modulated (PCM) audio interfaces with the same four wires for one or more channels. In the general case, word select is re-named ‘frame start’ and pulses once to coincide with the first bit of the first channel on a multi-channel bus.
Early audio codecs were simply DACs and only required digital audio. Now codec can be far more sophisticated and their advanced features, like DSP and audio path switching, need controlling.
In the case of NXP, digital audio is expected over I2S, and control over I2C.
On Revision 2 of the Raspberry Pi PCB, connections for these two busses are bought out next to the GPIO pin headers on P5, a footprint which allows a second 0.1in pitch header to be soldered in.
Differences between Revision 1 and Revision 2 boards are on the Foundation’s website.
Revision 1 board owners might be locate and solder to the I2S signals here (scroll to the bottom) – But be aware, should you need them, that I2C busses were swapped around between revision 1 and 2.
Lemmers’ need at NXP is to work with the firm’s TFA9890, a ‘smart’ amplifier for phones.
It gets the smart tag because it can push up to 3.4W into a tiny ’0.5W’ phone or tablet speaker by continuously measuring the speaker’s dynamic impedance, using an on-die DSP, and automatically notching out audio content at that resonant frequency.
“I was looking for an informal platform to do our tests. Raspberry Pi is a very cheap, open platform. I could have ripped down a phone, but the signals are not easily accessible,” he said. “For our initial test, with only playback, we connected three I2S wires plus ground from the Raspberry Pi connector, and I2C.”
For software, to get something up and running, Lemmers picked up an existing Linux device driver which produces a generic I2S interface.
In this case, it was the driver for the TDA1541 – a near-legendary I2S input two channel 16bit DAC from the early CD player days – before cheaper one-bit noise-shaping DACs took over.
As this chip has no advanced features, its modes are pin-selected, it needs no control bus and can be wired straight to power and the Raspberry Pi I2S pins to give a high-quality audio output once the driver is working – if you can find one of the elusive chips.
Lemmers just used the driver to kick-start the I2S bus for his chip, but there are plenty of people around connecting 1541s to Raspberry Pis.
If your chip is a mono DAC, you need to connect two to the same bus.
“Our [TFA9890] device has a mono DAC and mono amp, so we have two devices and we send them commands over I2C to tell them which channel they should respond to,” said Lemmers.
Without a proper Linux driver for his chip, Lemmers manually sent the commands across.
“Linux provides an I2C user interface, run in user mode. Our next step at NXP is to create a real Linux driver for this particular device in audio framework of Linux,” said Lemmers. [see below].
This will include speaker-dependent calibration data for the 9890 resonant frequency algorithms.
So if Lemmers was not doing his day job, and wanted to send quality sound from a Raspberry Pi into a Hi-Fi, what would he do?
It transpires, he has already tried it: “I have an Apple TV, and I was curious. I borrowed one of the Raspberry Pis and installed XBMC. It took me half an hour to do something better than Apple TV.”
This is something Electronics Weekly has also tried, and the results are excellent.
In both cases, audio was extracted from the HDMI digital stream – While Raspberry Pi analogue audio output is not so wonderful, its handling of digital audio over HDMI is.
There are expensive HDMI audio breakout boxes, but some computer monitors include HDMI DACs – Electronics Weekly used a ViewSonic VX2260wm.
To get sound straight into a Hi-Fi without going through HDMI “I would use a codec from our UDA13 series,” said Lemmers. “If I had to choose, it would be a UDA1355 which can be used to produce S/PDIF output from I2S. If you have S/PDIF, you could create a Toslink fibre optic output.”
S/PDIF is Sony/Philips Digital Interconnect Format, used in both fibre-optic and wired forms for Hi-Fi.
Lemmers prefers digital links between to his Hi-Fi, but should you want analogue links, the same 1355 can be switched to deliver audio at almost 90dB THD+noise thought an on-board stereo DAC.
Putting together a software driver is not trivial, but there is plenty of help around.
“Creating a driver for the 1355 should not be that hard”, he said. Software already exists for similar hardware. “UDA1380 and UDA1344 are codecs from our department supported by default in a Linux kernel. Or use user-mode to send over the I2C properties, you could use a small script. There are already open-source I2C tools.”
Lemmers recommends reading a blog by Koalo for further inspiration.
“The nice thing about Linux is that if you have driver, in theory the software will work everywhere,” said Lemmers. However “you still have to formally test it to make sure the hardware timing works. It does not always.”
Back in the lab, Lemmers is working on proper control software for the 9890. “Now we are creating a real driver for this particular device in the ALSA SoC audio framework. It is an audio architecture used in Linux. It is also used in Android at the lowest level. It is a framework for audio back ends and you can generate an audio codec plug in for ALSA SoC.”
A blogger called Pasdesignal has written in detail on modifying the Raspberry Pi kernel for ALSA SoC audio – also known as ASoC audio.
There is also Broadcom’s limited data sheet of the Raspberry Pi SoC to the Foundation website.
There are advantages to creating software around an open-source standard and popular hardware: “This has a nice spin-off. Once it is available with the Raspberry Pi hardware, customers will be able to try out our codecs and contributors to open-source can use, debug, improve and add to the code,” Lemmers said.
This code could then be used by app writers for phones using the NXP codec. “They can make the phone sound different in different circumstance,” he said, cautioning: “They have to know what they are doing, so they don’t blow up phone audio.”
It is early days for high fidelity audio from Raspberry Pi.
Audio through HDMI already works, and can be used through RaspBMC and several other sound playing Linux packages.
Existing Linux drivers will not need much work to produce high-quality analogue audio via the I2S from straight-forward audio DACs like the TDA1541 – and there are plenty of similar DACs up and down the audio quality scale.
Beyond this is more sophisticated audio codec hardware, controlled over I2C or some other interface, using more sophisticated drivers to produce analogue or other forms of digital audio.
If an analogue audio output is required, some thought will have to be put into effective grounding, particularly between the Pi and add-on board, to keep noise down.
And an analogue buffer might be needed to drive the output cable – the venerable NE5532 will do this without spoiling fidelity if you can find it a -5V rail.
For a fine discussion on grounding and line driving, NwAvGuy has a particularly good design article on his Objective2 headphone amplifier, and also a detailed design article on a USB-connected audio DAC – the ‘ODAC’.
For more on USB-connected Raspberry Pi audio, the RaspyFi Project is worth a look