0

Situation Diagram

In this issue, the microphone at point A records audio, compresses it, and sends it to the server at point B somewhere "in the cloud." The point B server then figures out what rooms the recorded data is going to, and distributes it over the devices in the rooms.

The issue is that, of course, since the server is off-site, it takes X amount of time to travel from point A to C, and the sound waves travel back to point A again to be re-recorded and played back creating an echo.

I've been using software acoustic echo cancellers to try and eliminate this echo, but apparently even Adaptive AECs require a knowledge of how long the delay is. My guess is that all AECs were designed to eliminate echo in situations like speaker phones where the delay is a number of milliseconds and easily known. I get the feeling when I read that a lot of echo cancellers have a finite max echo buffer.

So the question is, how can I figure out the echo delay to eliminate it based on the following:

  1. The room the person is in may change since the sender device is mobile.
  2. The rooms can be across multiple sites with different connexion speeds.
  3. The delay is based on Internet speed. This means that the delay may change anywhere from 100ms to 2s based on time-of-day and other factors.
12
  • 2
    Just send a test sound and measure the delay? Unless you expect that your network service will have massive spikes, this will be more than enough.
    – Ordous
    Commented Jul 21, 2015 at 14:35
  • How can I detect which room the user is in to measure the delay? The rooms can be across multiple sites. Commented Jul 21, 2015 at 14:55
  • Ah, I assumed that since this is VoIP, your senders and rooms were parts of single applications (i.e. one application is a sender/room pair). If they are not, and this is more of a multi-microphone to multi-speakers system, then you may want to send a signal to all rooms in order and calibrate all senders at the same time. This leaves the problem of a user joining mid-conversation (as you don't want to disrupt that with your testing), but you can usually assume that the first several seconds of stream from a user is just them breathing + ambient (and echo) sounds and use that to align.
    – Ordous
    Commented Jul 21, 2015 at 15:00
  • When you say "sending a signal", do you mean sending a demo piece of audio that isn't hear-able by the human ear to calibrate before making the recording? Commented Jul 21, 2015 at 15:07
  • Yes, or audible if you're worried about microphone quality - I imagine it doesn't matter before the recording.
    – Ordous
    Commented Jul 21, 2015 at 15:12

1 Answer 1

1

There are two ways I see to solve this problem, one relies on changing the current system architecture, the other will be difficult to implement, and may not work amazingly well.

without changing the architecture, you may use autocorrelation to estimate the channel delay. If it is somehow possible for you to maintain a particular channel delay, then this isn't too hard, as the server plays audio from the speaker, it just has to perform continuous autocorrelation measurements on the audio input to calculate the delay. To deal with the user moving, you'll need to track the delay, you can do this by slicing the audio into time segments ( maybe ~100ms) and perform the autocorrelation independently. If you can't guarantee the internet delay is stable, then this tracking algorithm will have to also deal with large discontinuities in the delay measurement. Honestly this approach sounds like hell. but its probably possible. Your PCM compression might degrade this approach, as although codecs like MP3 and OPUS are pretty transparent to our hearing, they cause a massive degradation in the SNR of the audio, and will really degrade your ability to perform autocorrelation, or just processing in general.

I would recommend adapting the system architecture. One option might be to have the receivers 1 & 2 collect the audio from the recorder locally when the recorder is in range. then it can determine the channel delay in the same way and perform the AEC itself. This has a huge advantage of being able to work on full resolution audio, which will make the AEC and autocorrelation work better.

Another even better option might be to have receivers 1 & 2 also record audio, if the server determines that the microphone is in the vicinity of 1 or 2 ( again using autocorrelation) it will mute the microphone and use the audio from the corresponding receiver. Then you can use existing implementations of AEC used in conference call devices.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.