Automating audio interface testing on embedded platforms -

Automating audio interface testing on embedded platforms

The audio interface has become ubiquitous nowadays. It is available on most of the single board computers (SBCs) for the industrial Internet of Things (IIOT). There are multiple type of interfaces available ranging from analog audio to digital audio ports. Each type of this interface has its own challenges in design and testing. Testing of these interfaces during assembly and production involve the complete path from analog or digital front end to the digital audio input ports of a processing unit.

The audio front-end on an embedded platform and generic flow of audio data path in a production test setup environment is shown below (Figure 1),

Figure 1: Test Setup & Audio Front-end for an Embedded Platform (Source: Author)

The above diagram shows the major blocks/components present in the data path. The receiver IC present can be analog front end IC such as an analog-to-digital converter (ADC) or also can be a digital audio receiver IC. The output of the IC can be in any serial format like Inter-IC Sound Bus (I2S). This interface can carry raw audio data in pulse-code modulation (PCM) format.

The aim of the production testing is to ensure that the complete audio path is functionally tested for all kinds of issues. The possible issues can include the following:

  • Front end receiver IC failure.

  • Assembly related issues on I2S lines like stuck-at-high (connected to supply) or stuck-at-low (connected to ground) or shorting between multiples signal lines.

This audio interface testing will be a part of a bigger production test system that will test all the interfaces on an embedded board.

Listed below is one common technique used for detecting assembly related issues in audio interface testing. For front end receiver IC failure, different technique needs to be used but those techniques are beyond the scope of this document.

Technique 1 – Subjective Testing

Subjective testing involves capturing audio data samples for few seconds and comparing them with the actual audio being played by hearing inspection. The drawback of this technique is that it needs human intervention and is time-consuming. For example, if there are multiple stereo channels, then the user needs to listen and confirm one after the other.

Considering the drawbacks of the above technique, we have come out with an innovative way to test the audio interface signals and automate the whole process.

Technique 2 – Automated Testing

To understand this automated-testing technique it is important to understand some fundamental concepts of the I2S interface.

I2S has three signals – BCLK (bit clock), WCLK (word clock), DATA (data signals). If the BCLK or WCLK are not proper (stuck at high/low) then the processor audio input port will fail to capture and will give a corresponding result showing clock failure. If these signals are fine, then audio capture will happen irrespective of the value of DATA. Now if DATA is stuck at 1 or 0, then the audio data buffer will contain all FFFF or all 0000 for each 16-bit sample. Thus when we generate the MD5 checksum, we will get two corresponding values: MD5(FFFF) and MD5(0000). For every other value of audio data, the MD5 checksum will be different. This concept can be used to automate and check the audio capture signals.

The procedure for this method is to capture the audio when proper audio is playing and is not in mute condition. This will ensure that our audio file is only captured and the data in buffer is correct. Once an audio data buffer has captured about 100 samples, then its MD5 checksum can be generated. If the DATA signal was stuck at high then its MD5 checksum value will be same as MD5(FFFF) and if it was stuck at low then its MD5 checksum value will be same as MD5(0000). If the DATA signal is toggling then the MD5 checksum value will be any other random value. Hence based on the MD5 checksum value, we can come to a conclusion on whether the DATA signal has any issues.

Usually, these I2S lines will have multiple data signals. We can demonstrate this with the following example of I2S bus with four data signals DATAx (x = 0,1,2,3). This can be done by giving audio data on one of the DATA signals and 0 for all the remaining data signals. This way when we can generate MD5 checksum of captured data of all DATAx (x = 0,1,2,3) and confirm that MD5 checksum values are as expected.

If we have given audio data on DATA0 only, the MD5 checksum for DATA1-3 signals should be MD5(0000) and for DATA0 it should be some random value. This can be done for all the four data signals one after the other in four iterations as shown in Table 1.

click for larger image

Table 1: Iteration of Audio Testing (Source: Author)

The limitation of this technique is that it can be used to only identify the issues described above. For some use cases, it cannot distinguish between the issues. For example if multiple signal lines are shorted then the technique can detect that an issue is present but it cannot clearly say which lines are shorted together.


The above mentioned methods have been tested and are being currently used successfully to test audio input interfaces across many hardware boards developed by Ittiam. We have seen that it has reduced the overall testing time of audio interfaces resulting in lower board testing cost.

Ayusman Mohanty is a product architect with key focus on building hardware for video and audio broadcast and surveillance systems. He can be reached through Linkedin.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.