Background

In this post we will discuss the challenge of synchronizing the audio that is given as the input to the echo cancellation software running on Android. This post is a continuation to a blog series we published on echo cancellation and specifically on the post that deals with importance of synchronization in echo cancellation. This post is targeted for VoIP developers on Android but can also be relevant for developers of VoIP solutions on other mobile platforms as well.

A Case Study

In the following graph you can see an example of audio streams that were provided as an input to the echo canceller.

Speaker minus microphone bytes

The Y-axis is the difference in the total number of bytes that was received by the AEC – i.e. the total number of bytes that were received from the speaker (reference signal) minus the total number of bytes that were received from the microphone.

The X-axis is the total number of calls that were made to the AEC.

If we analyze this graph, we see that after the first few calls, the graph is relatively stable until we reach the ~85 call. In this area we see a huge increase in the number of speaker (reference) audio data that was received compared to the number of microphone audio data. In total there is a jump of over 15,000 bytes which implies an audio worth of ~1 second for this 8khz VoIP application. Immediately after this “jump” in the graph we see a significant decreasing slop in which the echo cancellation received many more bytes coming from the microphone.

As you can now realize, such extremely non-synchronized behavior can cause the AEC to:

1. Loose track of the echo tail.

2. Become “blind” to the echo in case it is received before its reference signal was received.

Tips for resolution

Each VoIP application has its unique architecture and functionality that should be taken into account. Nevertheless, below is a minimal check-list that we suggest to review:

1. Callback mechanism. Android OS is very sensitive to delays in callback functions.  This means that a VoIP application should be designed using an architecture that minimizes the delays inside callback functions. This can be done using mechanisms like cyclic buffers etc. You can contact us to discuss the details for your specific application.

2. CPU power. When planning and developing a real-time VoIP application you should take into account the available CPU power for echo cancellation. You should take into account basic platform capabilities (e.g. supported instruction set) and also the required real-time functionality  (e.g. support for video in addition to audio). For example, on platforms with limited CPU power, when video is turned ON, the AEC should probably be set to an optimized-CPU mode.

3. Testing, testing, testing. Make sure you test the behavior of your application in different scenarios both in the lab and in the field.

How can we help ?

Based on our vast experience in this field, we offer a technology that can support you from cradle to grave:

1. Versatile technology that can be deployed in numerous conditions.

2. Technology that keeps with the paste of changes in this market. For example: support for new capabilities, support for new platforms, updated usage scenarios, etc.

2. Seamless monitoring and testing capabilities that can help you to automatically monitor and test different aspects of echo-cancellation performance in your lab and in the field.

In addition to the technology itself, our professional support team works with you to identify, analyze and resolve issues that you might encounter from time to time.