Мы пытаемся написать приложение, которое использует webrt c для передачи аудио только между двумя пирами. Мы добрались до стадии, когда устанавливается вызов, и начинается вызов. Один из них является веб-браузером, другой использует скомпилированную версию библиотеки g ++ cbr webrt c.
Кажется, что звонки имеют идеальное качество (с использованием кода opus / 48000/2 по умолчанию c) через 5 секунд. Тем не менее, первые ~ 5 секунд звонка иногда звучат ужасно (особенно если смотреть на нативный-> звук браузера). Иногда происходит потеря звука, и чаще всего голоса звучат приглушенно и их трудно понять. Это падение качества в первые несколько секунд обычно соответствует скачку джиттера, обнаруженному инструментами разработки chrome:
Собственный компонент подключен к собственной звуковой карте и работает с использованием тактовых импульсов, которые доставляют каждые 10 мс 960 байт одноканальных данных pcm в библиотеку webrt c через пользовательский AudioDeviceModule (вызывая RecordedDataIsAvailable). Несмотря на то, что наше приложение вызывает этот метод каждые 10 мс, как по маслу, мы наблюдаем странную закономерность во времени отправки пакетов SRPT от нативного однорангового узла к одноранговому узлу браузера. Используя wireshark, мы фиксируем эти временные характеристики пакетов и измеряем задержки в миллисекундах.
Пример задержек в начале вызова (в миллисекундах) с ptime 10 в SDP:
5.50 42.78 1.33 4.44 0.16 17.90 5.85 11.14 6.87 4.10 3.26 7.63 6.21 11.78 11.37 5.79 10.98 10.84 11.26 10.76 10.99 6.00 12.00 12.21 5.79 10.12 10.88 10.13
Кажется, проблема в некоторых настройках / опциях в собственной библиотеке WebRT C, которая вызывает буферизацию и отправку пакетов со странным раз. Тем не менее, у меня, похоже, нет ручного доступа для изменения каких-либо настроек, относящихся к этому (буфер дрожания предназначен для входящих пакетов - поэтому эти параметры, похоже, не актуальны). У кого-нибудь есть опыт подобных проблем или идеи о том, как мы можем поступить?
Спасибо