HD Audio from ground up (Part 1)

There are different ways for a system to interact with the real world. Starting with the use of a simple LED that describes the state of a process and going all the way down to complicated graphic LCDs. There is one method that developers rarely consider, mainly because the resources were not widely available or because the results are not very impressive. This method is audio.

Systems that use sound usually create different type of tones, either to indicate that the user must pay attention to something, or to indicate some measurement using pitch or pulse frequency (reverse parking alarms). Other more industrial systems have pre recorded speech in applications like the floor level announcing in elevators, but there are many more scenarios that could benefit.

Industrial audio systems are often have limited functionality as they mostly use the internal DAC and memory of their microcontroller (Block Diagram 1). This configuration is always limited for two main reasons.

Firstly, the internal DAC is not designed specifically for audio, it is a general purpose DAC in a general purpose microcontroller. Secondly, the limited size of the internal memory, often Flash and measured in kilobytes, means there is limited space to audio samples, and so a quality/space trade-off must be made. Additionally, as the flash is internal to the microcontroller, the audio samples are hard coded into the program, offering little user configurability.

Imagine, for example, an access/security system that can indentify if someone can cross a specific area. The system could welcome that person and inform them of relevant information based on their profile. If the person does not have access to the area then the system can assist in finding the closest exit, or how to gain access. All of the interactions could be make in HQ audio, feeling like a natural voice making the user to interact with the system more naturally.  Note that speech recognition is beyond the scope of this article. 

It is easy to create a specification sheets and describe systems like above, but actually prototyping such a system is a different matter. By taking advantage of the mbed microcontrollers rapid prototyping features, we are going to create a high quality audio module from ground up. We’ll start from the passive components of the first hardware prototype and the first test code to drive it, and build all the way up to a library API, with examples.

In order to start the implementation we will focus in the beginning to something that will look like that block diagram below (Block Diagram 2). The mbed will take data from an SD card and will drive the external DAC.

A SD card interface complete with a file system implementation already exists in the mbed Cookbook, along with reference circuit diagrams and cool projects showing it in action. The next piece of the puzzle is the external DAC, and how to connect this to the system. Maybe the answer is the I2C or SPI protocols, or maybe a good old parallel communication (yes, you can still find DACs with parallel communication with the internal control logic).  We have I2C and SPI libraries available that have been tested and are ready to work, so that would be an easy option. However, that might not deliver the quality we are after.

 Audio DAC selection

We defined in the beginning that we want to build a high quality audio module, and you don’t have to look far to find that an audio communication protocol already exists. The answer is the Integrated Interchip Sound or commonly known as I2S (http://www.nxp.com/acrobat_download2/various/I2SBUS.pdf). It has been around for more than a decade and is the preferred communication method between the DSPs/Microcontrollers and the external DACs to almost all of the audio consumer products like portable mp3 or desktop DVD players. The good thing is the NXP’s LPC1768, the Cortex-M3 microcontroller that powers the mbed, has already an internal hardware I2S protocol module that we can use.

The protocol consists of three signals (Timing Diagram 1). The data line (SD), the bit clock (SCK) and the word select (WS). The data line carries the audio information (MSB first) and may be synchronized with either the falling or the rising edge of the clock signal. The word select indicates the channel being currently transmitted with logic ‘0’ meaning left or “channel 1”, and logic ‘1’ meaning right, or “channel 2”.

Notice how the WS signal changes state one clock period before the MSB of the next channel is transmitted, enabling the receiver to store the previous word and clear the input for the next stream.

Time Diagram 1 – The I2S protocol

Now that we have identified the appropriate protocol, we must select the DAC part for our implementation. As you will discover from a quick search, the number of I2S compatible DACs (at very competitive prices!) means we do not need to make compromises when making a selection.

One of those available DACs is the TLV320AIC23B from Texas Instruments. It is a high performance multi-bit sigma-delta stereo audio codec (http://focus.ti.com/docs/prod/folders/print/tlv320aic23b.html) that use the I2S bus to transfer audio data. This part can support audio data word lengths of 16, 20, 24 and 32bit, with sample rates starting from a modest 8 KHz stretching all the way to 96 KHz, enabling the audio quality we are trying to achieve. The analog features consist of stereo-line inputs and outputs with an analog bypass path, 30mW per channel integrated headphone amplifier (into 32Ohm speakers) with volume control and mute functions. Additionally, the DAC also includes an ADC, so that it can sample audio and transfer the data over I2S, enabling audio record as well as playback.

The DAC can work as a master or a slave on the I2S bus, and its control registers can accessed over a SPI or I2C interface. The different available package options mean we can work with a package big in dimensions for the first prototypes (good for probing purposes) and we can shrink our PCB later with the tiny dimensions of the QFN parts. 

Starting the design

In order to start designing with this DAC, we must first check the datasheet and make some notes about the supply power, clock, the input and output lines, any demand for special passive and discrete components etc. This helps to gain an understanding of how a chip works and to help eliminate design mistakes. 

The first paper design of the system we are planning is shown in Block Diagram 3. We will create a flexible “break out board” that can be reused for different applications, which will include the following features

- Local oscillator for the DAC device, so that it can be a master or slace on I2S bus.

- An I2C and SPI bus for programming the control registers (volume, balance, sample rate and so on.

- Audio output and input connectors, so we can record and playback audio.

- All of the supporting components required.

The hardware design process will include the addition of a few passive components like decoupling capacitors; pull up resistors and so on. 

Block Diagram 3 – TLV320AIC23B

From the abstract diagram above we can go to a picture closer to reality with the one that follows. It is the footprint of the DAC in a SOIC package (or PW package for Texas Instrument). Some of the pins are coloured indicating different functionality, like the positive power pins (with red) and the ground pins (with black). The pins we need to implement the features we need are coloured in green. The remaining pins will be left unconnected as we don’t need the functionality that they provide, at least for our project. 

For the full design process: http://mbed.org/cookbook/HQ-Audio