How Voice Codecs Are Adapting to MEMS Microphones

October 23, 2020 David Brooke, Wireless/Wireline Voice & Data Product Manager, CML

Low-cost, low-power microphones are an essential component in many devices nowadays, from wearables to cars. As voice interfaces and digital assistants become more popular, there will be a growing need for compact, affordable subsystems that can take an audio input and convert it to digital data.

The technology of choice today is often Micro Electrical Mechanical Systems (MEMS), with MEMS microphones becoming near-ubiquitous in many consumer applications. MEMS microphones have good performance, in terms of sensitivity and signal to noise ratio, and are physically very small.

Despite these advantages, a lack of suitable interface devices has been a limiting factor in the usage of MEMS microphones. Voice codecs have, in the past, been designed to handle analogue microphone outputs, and most modern codecs have been developed to address the needs of multi-media devices. While analogue MEMS microphones are available, the digital versions are usually the preferred choice, as they are easier to design with and integrate.

How can designers ensure they get the best of both worlds, taking advantage of all the benefits of digital MEMS microphones, without requiring complex additional interface circuitry, that can be slow to design and costly? This is particularly relevant in IoT and consumer applications, where cost is critical, and time to market is key.

The MEMS microphone

Figure 1 shows a typical MEMS microphone design. The changing air pressure due to sound waves makes the membrane flex, which therefore alters the distance between the membrane and the fixed, rigid back-plate. This changes the capacitance, giving us an electrical signal that tracks the sound levels.

This kind of MEMS microphone is simple to fabricate in silicon, and with the mechanical device and electrical circuitry in a single chip, it is easy to integrate into a circuit design.

(Figure 1: MEMS microphone transducer)


Figure 2 shows a digital MEMS microphone, where the transducer output is amplified, converted to digital and then modulated to produce an over-sampled, one-bit PDM (pulse-density modulation) output. This output then requires further signal conditioning before it can be used by an application, most of which require input signals in the standard PCM (pulse-code modulation) format.

(Figure 2: Digital MEMS microphone block diagram)


Handling the digital signal

To process this digital output, designers could implement PDM to PCM format conversion and then digital filtering on a microcontroller. However, this approach is slow, and requires particular skills that may take too much time for a designer to learn.

A better alternative can be to use a codec that is specifically designed for a digital MEMS microphone. One example of this is CML’s CMX655D, which is shown in figure 3. This integrates the essential MEMS microphone interface functionality onto a single low-cost, ultra-low power device.

(Figure 3: simplified block diagram of CMX655D voice codec)

The device can interface with two microphones simultaneously, supporting external noise cancellation applications, and also supports multiple different frequency ranges. A high-efficiency, Class D amplifier, provides an audio output, which is required for applications such as smart speakers.

Open source development tools

While an integrated codec, such as the CMX655D, has many advantages, it does mean there are many options for the designer to choose from in configuring the device. This means there is a requirement for toolkits to help with development, and to support prototyping and evaluation. On the other hand, as speed to market and cost are critical, there is a risk that a complicated development kit could act as a barrier to designers.

To overcome this, open source approaches can provide familiar tools and interfaces, with low-price, readily available hardware. Specifically, the Raspberry Pi (RPi) has proved a popular choice in many applications, providing performance and flexibility at minimal cost.  

The Hardware Attached on Top (HAT) interface provides a standard that makes it simple to attach third-party hardware to a RPi. HAT defines a 65 x 56mm physical format, and the pinout for a connector, as well as supporting an automatic configuration system where the RPi can recognise the HAT board that is connected to it.

To make development easier, CML offers a HAT board, the EV6550DHAT (figure 4), which means the CMX655D codec is now compatible with the RPi environment, and designers can work within a familiar Linux environment to develop their applications.

(Figure 4: The EV6550DHAT HAT board)

Having access to Linux also opens up the opportunity to use other open source software. One example is the ALSA (Advanced Linux Sound Architecture) framework, which is part of the Linux kernel and provides an API for sound card device drivers. By releasing an installer for this driver for the E6550DHAT, CML enables the use of any high-level sound app that is ALSA compatible, thus further simplifying development.

As MEMS microphones continue to grow in popularity for IoT applications, this kind of open source-based approach means that developers can gain access to low-cost, powerful software and hardware. Overall, this allows them to cut time to market, and focus their effort where it matters – on creating differentiated products for their end customers.

About the Author

David Brooke has nearly 40 years of experience working in the electronics industry. As CML’s Wireless/Wireline Voice and Data Product Manager, specialising in baseband solutions, he works across all CML departments managing the products under his care. When he gets some time to himself, he can often be found cooking at home with a glass of red wine in hand

Previous Article
Pitfalls in C: Declaring Variables
Pitfalls in C: Declaring Variables

C is the most commonly used language for embedded, with good reason. It is expressive, compact and powerful...

Next Article
Reduce DFT Footprints in ASIC Design by Addressing Test Time
Reduce DFT Footprints in ASIC Design by Addressing Test Time

An Approach Using Test Channel Reduction to save Testing Cost