2

I'm calculating sound card drift for reasons of acoustic echo cancellation. My algorithm is:

drift = samples_played - sampled_recorded

Where *samples_played* is incremented by 1 when a 320, 640 or 1920 byte audio frame is sent to the playback device and where *samples_recorded* is incremented by 1 when a 320, 640 or 1920 byte audio frame has been output by the capture device.

A description of what I am trying to accomplish is provided by WebRTC as follows:

WebRtc_Word16 skew Difference between number of samples played and recorded at the soundcard (for clock skew compensation).

My question is two-part:

  1. Is the algorithm correct?
  2. Is the increment correct?
Brad
  • 159,648
  • 54
  • 349
  • 530
junglecat
  • 643
  • 1
  • 10
  • 19
  • Why are you using those byte sizes? You would need an awful lot of audio data for a single sample to be 320 bytes. Can you expand a bit more on what you are trying to measure? You want to know the full latency for playback and record? Or are you measuring clock drift? – Brad Mar 31 '13 at 07:25
  • 320, 640 and 1920 are common frame sizes for VoIP. – junglecat Mar 31 '13 at 07:39
  • Ah, then your method is wrong. You will find many more than one sample per frame. Since clock drift isn't very fast (usually), you will need to find a way to get down to the sample level, if possible. – Brad Mar 31 '13 at 07:46
  • The sample sizes are 160, 320 and 960 respectively (frame size in bytes / sizeof(int16_t)). – junglecat Mar 31 '13 at 07:55
  • Also, I've added more detail to the question. – junglecat Mar 31 '13 at 08:02

0 Answers0