From a82c2ede6aade5d0613c3bef36979a74cf9d902f Mon Sep 17 00:00:00 2001 From: evgeny Date: Thu, 15 Oct 2026 02:58:42 +0200 Subject: [PATCH] Clarify audio diagnostic timing and reporter lifetime --- doc/chat_call_arch.md | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/doc/chat_call_arch.md b/doc/chat_call_arch.md index 9c82cbb0..64619ee4 100644 --- a/doc/chat_call_arch.md +++ b/doc/chat_call_arch.md @@ -138,7 +138,7 @@ INFO-логи Android показывают длительности настро на API 26–30 запрашивается такой эффективный размер буфера, с учётом ограничений устройства. Прежнее заполнение всей ёмкости на Samsung оставляло около 140мс между written и played (на desktop 60–80мс). Лог `playback buffering` показывает принятый порог и ёмкость; -ежесекундный `clock` — queuedUs, текущий порог и underruns, прирост underruns имеет уровень WARN. +ежесекундный `audio summary` — queueUs, текущий порог и underruns; новый episode underrun имеет уровень WARN. Это очередь AudioTrack, а не полная сквозная задержка и не сетевой jitter reserve. Повторный замер: startFrames=1920 принят, но written-played остался 140мс; одного стартового порога недостаточно. @@ -148,9 +148,19 @@ INFO-логи Android показывают длительности настро целевым запасом/разбросом доставки JB, темпом, недостающим PCM и отдельными счётчиками JB/AudioTrack. Снимок JB не сбрасывает события для CALL_STATS. encodedMs — очередь Opus после pull, processingMs — оставшийся PCM SoundTouch в длительности исходной речи; reserveMs зависит только от доставки. -AudioTimestamp опрашивается раз в 200мс, его frame/time и время опроса печатаются отдельно; +Reporter опрашивает AudioTimestamp, routedDevice, underrunCount и размеры буфера не чаще раза в 200мс. +Playback читает только опубликованный неизменяемый снимок. Его begin/end и возраст deviceAgeUs +отличают задержку опроса от задержки аудио; stampQueryUs/routeQueryUs/propertiesQueryUs показывают стоимость запросов. +Android API может удерживать общие внутренние locks даже при вызове из reporter: перенос убирает +прямое ожидание диагностического запроса в playback, но сам по себе не доказывает отсутствие влияния на write/head. +frame/time аппаратного timestamp и время начала опроса печатаются отдельно; при недоступности стоит stampOk=0. Времена trace — MONOTONIC; очередь устройства — written-played. Эти показатели нельзя складывать с возрастом AudioTimestamp как независимые задержки. +В playback отдельно измеряются writeCallUs (только вызовы write), headCallUs (чтение позиции), +progressCallUs (публикация позиции ядру), jbSnapshotUs (нативный снимок), writeSpanUs (весь цикл записи) +и blockUs (pull до формирования строки). При частичных записях длительности вызовов суммируются за блок. +Старое поле writeUs включало чтение позиции и прогресс: его нельзя трактовать как длительность одного AudioTrack.write. +Stop дожидается reporter, включая непрерываемый Android-запрос, до освобождения AudioTrack. `audio detail` сохраняет 2с до и 3с после старта, фактической смены routedDevice или новой аномалии: очередь устройства >100мс в течение секунды, отсутствие продвижения head 100мс при наличии данных,