Всем привет Пишу голосовой чат используя rpc_unreliable() через ENet (со сжатием

Question

Всем привет Пишу голосовой чат используя rpc_unreliable() через ENet (со сжатием

в opus через GDNative), даные идут по пути "клиент 1 -> сервер -> клиент 2" (стандартная Годотовская реализация, данные с сервера на клиенты пересылаются автоматически благодаря MultiplayerAPI)
Недавно обнаружил интересную закономерность:
Иногда, поток пакетов прерывается на 5-10 секунд, и соотношение полученных/потерянных пакетов выстраивается в определенную закономерность, например
"7 получено, 1 потерян" или "6 получено, 2 потеряно"

На скриншоте 1:
Статистика для каждого из 3-х клинетов принимающих голос от 4-го за N секунд
Позитивное число - цепочка полученных пакетов
Негативное - цепочка пропущенных пакетов
Длина пакета: 480 аудио кадров (mix rate = 48000), т.е. каждые 1 пакет == 10 мсек
Размер пакета: 100-200 байт (нагрузка на сеть - 10 кбайт/сек/клиент при 100 пакетах/сек)

Я решил провести вот такой тест (скриншот 2):
Связь между 4 клиентами на 1 машине через ЛОКАЛЬНЫЙ сервер (т.е. траффик в сеть не уходит) разбита на 3 временных промежутка (зеленый - полученные пакеты, красный - потерянные)

1 - шлется 200 пакетов/сек/клиент (нагрузка - 21 кбайт/сек/клиент)
2 - шлется 100 пакетов/сек/клиент (нагрузка - 10.5 кбайт/сек/клиент)
3 - шлется 50 пакетов/сек/клиент (нагрузка - 7.5 кбайт/сек/клиент)

(Объем пересылаемых данных уменьшается засчет сжатия аудио куска большего объема + уменьшения количества Годотовских и моиз хедеров (меньше пакетов == меньше хедеров))

Вопрос: логичен ли вывод, что потеря пакетов происходит из-за переполнения неких внутренних буфферов Windows и пакеты дропаются умышленно?
Или такой нагрузки мало для этого, и скорее всего переполняются какие-то буферы Godot/Enet?
Кто-нибудь знает в какую сторону копать про ограничения на количество/размер UDP пакетов в Godot/Enet?
Или переполнение буферов тут не при чем (а тогда что?)