С
эти 4800 в софт очереди - ты не знаешь, какие они - те, что прилетели 1700мс назад или 500 мс назад. но если ты дропаешь то, что не помещается в софт буфер, то backpressure и не будет, ты и не даёшь его создать, всегда вычитывая сокет
Size: a a a
2021 May 24
r
Если даю меньше данных, то задержка ожидаемая - 300-500мс
r
Они не могли прилететь 1700 мс назад. Если бы они прилетели, то их бы там уже не было. Устройство воспроизведения звука консумит сэмплы с постоянной скорость 16000 сэмплов в секунду. А буфера - всего 8000 сэмплов
П
а буфер как часто в аппаратный скидывается?
С
Данные равномерно идут? Бёрстов нет где-нибудь в сети? Сеть не битая? Повторные отправки, например?
П
И задержка как считается
r
Не реже раза в 100мс
r
1700мс - секундомером.
П
И не растет?
П
Можно на сеть wireshark'ом глянуть что там ходит. Ну и из шизы принтов навтыкать каких-нибудь, если совсем ничего не понятно. Без кода такое
r
За то время, что я несколько раз мерил не выросла
П
Вполне возможно что тупо сеть не справляется с потоком, но гадание на гуще жеж
r
Извиняюсь. Это больше rubber-duck debugging. Код выложить не могу. С сетью в порядке, хоть и wifi.
С
Я бы для начала исключил сеть - запустил бы всё на том же хосте. Так можно и задержку точнее мерить, и будет понятно, куда дальше копать
П
Навтыкать логов и думать
r
Угу. Уже долго тыкаю и думаю.
П
Хотяб в месте flush'а программного буфера в аппаратный. Ну и на каждый новый пакет, наверное, тоже
П
И смотреть что по времени
С
"в порядке" и wifi - вещи слабо совместимые. Помехи, повторы кадров, переаутентификация, что угодно может быть.
П
(вангую что вообще проблема где-то сбоку)