Document call latency measurements and capture period

doc/chat_call_arch.md

@@ -174,6 +174,28 @@ Backend публикует только числовой снимок в огр
 Счётчик sequence описывает полученные backend-сэмплы; отсутствие потерь очереди само по себе
 не доказывает непрерывность физического захвата. Проверять вместе с hole/overflow и route-событиями.
 
+Для захвата звонка desktop явно запрашивает период 20мс вместо дефолта PulseAudio 25мс;
+фактический период сообщает `audio: call-capture initialized`. Сборщик по-прежнему принимает произвольные чанки.
+Секундные замеры задержки при `call=debug`:
+- `voice-io: capture latency`: возраст первого сэмпла перед native feed (включает сам блок 20мс),
+  подготовка/AEC в worker и вызов native feed; диапазоны min/avg/max в микросекундах.
+- `voice-io: playback latency`: приблизительный остаток PCM после mix, включая частичный блок,
+  длительность pull и недостающие сэмплы. Это очередь приложения, отдельно от backend.
+- `AudioDiag: playback clock`: latency backend, задержка конвертера/cache и максимальный размер
+  backend-порции в микросекундах. При measured=0 нулевые границы не означают нулевую задержку.
+- `call audio TX timing`: ожидание g_mtx, обработка/кодирование под ним, ожидание posted task;
+  post включает ожидание lock при выполнении задачи, его разрешение 100мкс. На Android этот же
+  замер обработки включает программный AEC, на desktop AEC уже выполнен в capture worker.
+- `call audio TX queue`: число ожидающих кадров, возраст старейшего и avg/max ожидания кадров,
+  переданных роутеру за интервал. Отправка роутеру не является подтверждением доставки пиру.
+- Android `audio capture latency`: возраст первого сэмпла перед native feed и число измеренных
+  привязок; дополнительные поля старта устройств разделяют min-buffer query, constructor, routing и buffer setup.
+Возраст PCM содержит часть измеренной обработки: эти числа нельзя механически складывать.
+PTS/возраст используют локальный MONOTONIC, интервалы внутри native — локальный get_time_us/get_time_tb;
+эти временные базы и часы разных устройств напрямую не вычитаются. Все сводки формируются вне device callback.
+Период захвата 20мс и новые измерения требуют контрольного звонка; дополнительная desktop PCM-очередь,
+жизненный цикл подготовки Android и таймер показа видео этим изменением не менялись.
+
 На Android `CallPlaybackBuffer` подбирает рабочую очередь отдельно от JB/SoundTouch:
 после 30с наблюдаемого продвижения playback head без underrun пробует уменьшить её на один
 блок PCM (960 сэмплов, 20мс), до одного блока или фактического минимума устройства.