Задержка звука

Чтобы была более понятна суть проблемы, опишу конфигурацию всей системы.

Имеются 3 компьютера объединённые ЛВС 100 Мбит. На первом, назовём его ПРИЁМНИК, ТС3 клиент захватывает звук в режиме VAD.
На втором компьютере, назовём его СЕРВЕР, установлен ТС3 сервер.
На третьем, пусть будет ПЕРЕДАТЧИК, ТС3 клиент воспроизводит звук.

В момент старта системы задержка звука между ПРИЁМНИКОМ и ПЕРЕДАТЧИКОМ -- доли секунды. А проблема в том, что со временем эта задержка увеличивается. Примерно через 3 часа она уже превышает 1 секунду, что не приемлемо.

Версии клиента и сервера своевременно обновляются. Пробовались различные версии кодеков и битрейтов. Но, только перезапуск клиента на ПРИЁМНИКЕ позволяет "сбросить" задержку на минимум. ТТХ приёмника: Intel Celeron 3.06 GHz, 504 MB, Windows Server 2003

 

вот это кейс :)

 

соединены чем и через что?
понимаете ли вы суть UDP?
суть программного и системного кеша?

 

Витой парой категории 5Е от сетевой карты до управляемого коммутатора 2го уровня, далее через оптику и гигабитный канал на агрегатор и центральный маршрутизатор.

Нет, не понимаю. Это из-за них задержка со временем увеличивается, а при перезапуске клиента на ПРИЁМНИКЕ уменьшается до минимальной?

 

удп это неадресованный/широковещательный трафик(ну почти). если свич L2 то ему пофиг, он пакеты на этом уровне не обрабатывает.
вопрос - что у вас есть агрегатор?
вопрос - на маршрутизаторе трафик логируется/шейпится/маркируется/перенаправляется(нужное подчеркнуть)?
это я к тому, что если у вас "умный маршрутизатор", то он умеет "молоть трафик" а это забивает ему мозги, мб стоит отключить(хотя не факт что возможно).
системный кеш - это грубо говоря блок виртуальной памяти, выделенный на диске(не путать со своп/файл подкачки), для такого рода данных использется "горячий темп" - это как при воспроизведении видео большого размера с ютюба, или ещё откуда нить. так вот он имеет свойство "просаживать" доступность к диску операциями перезаписи(по тому что программа выделяет себе небольшой кусочек и эксплуатирует его) - это в сво очередь может приводить к некоторой задержке, но для этого должно пройти время(в зависимости от битрейта и размера обрабатываемых данных), чем "жирнее инфа в миксере" и меньше этот самый кеш, тем быстрее он "просядет".
тот кто воспроизводит звук, для начала пишет пакеты данных в оперативу, потом компиляет байтный код(двоичный который) в данные, согласно схеме отправленного пакета, потом отправляет кусочки на диск, клеит "читабельный" кусок данных и отправляет обратно в оперативу, которая уже работает с программой, которая свою очередь ворует пшеницу, которая в темном чулане хранится, в доме который построил Джек.... както так...
по сути, это неизбежно, ну или мощи для вычисления должны быть большими и настроить переменные системы(программы) которая взаимодействует с большим кол-вом данных, требующих обработки.
з.ы.
написал, на мой взгляд просто, если сильно непонятно, могу попробовать упростить форму изложения ещё больше

 

Это всё понятно. Но! Это ответ на вопрос "откуда берётся задержка". Сам же вопрос звучит как "почему эта задержка увеличивается со временем"
К тому же возросшая со временем задержка не сбрасывается до минимальной перезапуском того клиента, кто воспроизводит. А сбрасывается перезапуском того, что захватывает звук.
P.S. В качестве эксперимента параллельно установил MUMBLE. Не смотря на максимальные настройки по минимизации задержки, в MUMBLE она больше чем в TEAMSPEAK, но со временем не увеличивается!

 

надо покурить....