Коллеги! А не подскажет кто простые алгроитмы борьбы с т.н. "джиттером" при пакетной передачи голоса. Везде пишут про буферы длиной аж в 1-2 сек. Но, если идёт двусторонняя связь и на стороне удалённого абонента не достаточно эффективно давится эхо, то с задержкой больше где-то 500мс говорить становится не возможно. Нужны алгоритмы, не требующие такой задержки, но не дающие, с одной стороны "щелчков" при запаздывании/пропадании очередного пакета, а, с другой стороны, не накапливающие задержку из-за разбегания кварцев.

На самом деле подавление эха где-то до 150 ms задержки нормально работает. Большие задержки нужны чтобы с тем, что пакеты на источник приходят не в том порядке, в каком были посланы бороться (reordering). А с джиттером адаптивными методами борются - адаптивно подстраивают глубину буфера под трафик, оценивая параметры распределения количества пакетов в буфере. Правда, сначала свой "кварц" подтягивают под среднюю скорость поступления отсчетов из сети (ну или еще как компенсируют расхождение тактовых частот приемника и передатчика - можно повторять-вырезать кусочки сигнала, можно ресамплинг с управляемым коэффициентом передискретизации), а уже потом минимизируют глубину jitter buffer. Эти технологии в TDMoverIP используются. Там и можно почитать. Если всё это в своей сети предполагается использовать, то jitter можно заранее наперед оценить.

Спасибо за ответ! Но вопрос ещё такой, а как быть, если пакет либо вообще не пришёл, либо очень сильно запоздал. Либо, кстати, что делать, если вообще пакеты перестали поступать. Если ничего не делать, что в звуковом потоке слышны отчётливые и неприятные для слуха "щелчки". Вот как их грамотно "замаскировать"?

У меня было фактически скользящее окно sequence numbers, которые мы принимаем в данный момент. Пакеты с номерами вне окна просто отбрасываются. Размер окна определяется допустимой задержкой.



Я просто предыдущий пакет повторял чтобы меньше хрюкало. У меня по 48 8 kHz отсчетов в пакете передавалось (пакеты по 48 байт 64 kbps аудио с логарифмической компрессией).

Если потеряно несколько пакетов - начинал подавать нули на выход. Полезно вести счетчики отброшенных по seq number пакетов - если их становится все больше, то это знак того, что надо увеличить буффер.