Свой голосовой агент без внешних моделей

01Что стоит перенять и что оставляем своим

Из Codex полезно взять разделение звука, управления разговором и работы агента. Для изолированной сети эту схему нужно собрать на собственных ASR, LLM и TTS. Перенос ChatGPT endpoint или токена автономности не даст.

У нас уже есть большая часть нужных границ: браузерный клиент, WebRTC в src_core, отдельное распознавание, src_agent, сценарии и Postgres. Я бы не начинал с замены всего стека. Сначала ограничил бы очереди и работу в полёте, замкнул зависимости внутри каждой площадки и подключил обратный аудиотрек. После этого - единые события сессии и перебивание ответа.

Этот учебник идёт от фактического пути речи к варианту автономного развёртывания, затем к изменениям и их проверке. Таблицы сравнивают конкретные обязанности. Числа в критериях приёмки - предложенные цели для испытаний, а не уже полученные показатели.

Какие версии сравниваются

Успешные обращения к ChatGPT из прежнего учебника - исторические результаты, здесь они не повторялись. Для этого сравнения достаточно клиентского контракта. Мы не знаем внутреннее устройство серверного ASR/TTS, аппаратные ресурсы ChatGPT и его задержки в одинаковых с нашим проектом условиях.

К началу главы

02Сначала отделим транспорт от распознавания

WebRTC доставляет звук, но не понимает слова. ASR, или STT, превращает звук в текст. LLM выбирает или формирует текстовый ответ. TTS превращает этот текст в звук. Агент отличается от обычной модели тем, что может выбрать сценарий, вызвать инструмент, сохранить состояние и вернуть результат действия.

Поэтому вопрос "у нас тоже WebRTC, почему ответ медленнее?" решается измерением всего пути. После быстрого транспорта могут идти ожидание конца фразы, файл, несколько вызовов модели и ожидание полного TTS. Сам WebRTC эти задержки не убирает.

К началу главы

03Как сейчас проходит речь в webrtc-komaroff

Браузер согласовывает соединение через Core, а затем отправляет микрофон по WebRTC. Core декодирует и нормализует аудио, передаёт кадры в NATS. Соседний ASR bridge находит законченные фразы, записывает временный WAV и отправляет файл в LinTO. Только после получения текста начинается работа агента.

Полученный ответ сценария сохраняется вместе с состоянием сессии и публикуется как текст или команды интерфейса. На схеме LinTO и LLM вынесены отдельно: текущая конфигурация использует соседний вычислительный контур, а не обязательно интернет. Для независимой площадки этот контур всё равно надо перенести внутрь её границы.

Обратный аудиотрек предусмотрен типом соединения sendrecv и обработчиком peer.ontrack в браузере. Но в проверенных handle_track и графе нет TTS producer и назначения его трека в sender Core. Наличие HTML audio element не доказывает, что агент говорит. Этот вывод относится к просмотренному voice-agent пути, а не ко всем экспериментам и TTS-демонстрациям репозитория.

К началу главы

04Что передаётся на каждом участке

У одного разговора несколько разных форматов. Между браузером и Core идут сжатые медиапакеты. Между Core и bridge идут сырые сэмплы. Между bridge и ASR снова файл с контейнером. Агент получает только текст. Ни один из этих форматов нельзя без преобразования подставить вместо другого.

Речь поступает кадрами, пока пользователь говорит. Распознавание одной фразы стартует после решения VAD, а агент - после final transcript. Pending показывается раньше текста, но не означает, что partial уже распознан. В этой последовательности результат Agent публикуется по NATS/WS: стрелка к браузеру не является новым прямым HTTP вызовом Agent.

Один кадр: 640 байт аудио, не считая метаданных

# Модуль нужен для UTF-8 представления метаданных перед сырыми сэмплами.
import json
# Производитель объявляет формат сырых сэмплов, а не MIME файла.
meta = {"type": "frame", "seq": 1, "sample_rate": 16000,
        "sample_width": 2, "channels": 1, "session_id": "00000000-0000-4000-8000-000000000001"}
# 20 мс × 16000 сэмплов/с × 2 байта × 1 канал = 640 байт PCM.
raw = bytes(640)
meta_bytes = json.dumps(meta, ensure_ascii=False).encode("utf-8")
# Длина метаданных идёт big-endian, сами сэмплы - little-endian.
packet = len(meta_bytes).to_bytes(4, "big") + meta_bytes + raw

Пакет type:end заканчивает поток и не содержит аудио. 16 кГц × 2 байта дают 32 000 байт/с и 50 сообщений/с при шаге 20 мс на одного клиента, до NATS overhead. Это арифметика, не замер пропускной способности. Base64 здесь не используется и ради сходства с OpenAI добавлять его незачем.

Старые поля LINTO_WS_URL в DRS не отменяют код _transcribe_and_publish: в исследованном bridge он вызывает HTTP. Какой image сейчас работает в production, в этом исследовании не проверялось.

К началу главы

05Как устроен голос Codex и чем он отличается от диктовки

В CLI 0.156.1 команда /voice начинает разговор: helper работает с устройствами и WebRTC, app-server ведёт управляющую часть, а ядро согласует разговор с агентной работой. Локальный app-server - не удалённая нейросеть и не обязательный посредник для каждого аудиопакета.

App-server создаёт call по HTTPS и принимает текстовые события по WSS sideband. Helper отправляет и получает медиа непосредственно через WebRTC. Эти роли могут быть разделены логически, даже когда app-server встроен в процесс TUI: штатный embedded client использует InProcess/mpsc, а не строки JSON в stdin. STDIO относится к нашим отдельным RPC-демо.

Границы того, что известно о ChatGPT

Клиентские исходники показывают отправленные поля и обработку событий. Они не показывают серверные ASR/TTS модели и не доказывают, что ChatGPT внутри собран как отдельные STT → LLM → TTS сервисы. В автономной системе мы сознательно предлагаем именно такой каскад: его компоненты можно поставить локально, заменить и проверить по отдельности. Сравнение не обещает разговорное качество ChatGPT на меньшем оборудовании.

Структура backend V3 в демо: session.model="gpt-live-1-codex", audio.output.voice="cove", delegation.type="client". Это исследованный версионный контракт, не публичная гарантия долговременной совместимости. Собственный сервис не должен эмулировать эту авторизацию или копировать cookies/attestation.

К началу главы

06Сопоставление обязанностей: что у нас уже есть

Сравнивать надо не имена библиотек, а границы работы. У нас есть аналог управляющей части app-server, но он распределён между Core, Agent и workflow runtime. Дополнительный сервис с названием app-server не нужен сам по себе: сначала достаточно согласованного интерфейса этих компонентов.

Три уже выполненных улучшения исключены из нового плана: deadline ICE gathering, очистка front ресурсов при отказе signaling и транзакция runtime+history. Остаются вопросы порядка ходов, отмены и идемпотентности tools: SQL-транзакция не отменяет уже выполненное внешнее действие.

К началу главы

07Что означает независимая сеть на практике

Изоляция означает, что новая площадка может загрузиться и вести разговор без основной сети, интернет-DNS, центрального брокера и внешних моделей. "Всё в Docker" для этого недостаточно: контейнер может обратиться к основному H100, скачать модель или загрузить style.json снаружи.

Не предлагаю свести всё к одной машине. Независимая сеть может содержать несколько серверов, включая собственный GPU. Для одной CPU-машины нужны отдельные тесты качества и задержек. Если одновременно модели и их локальные аналоги отсутствуют, останется только заранее описанный сценарный помощник с записанными репликами; свободный разговор обещать нельзя.

К началу главы

08Как собрать автономный контур, сохранив существующий проект

Предлагаю оставить браузер, aiortc, Agent, workflow и Postgres. Вокруг них задаём local-only профиль и добавляем обратное аудио. Голосовой Gateway здесь - ответственность Core, а не требование написать новый продукт или поставить Codex app-server в корпоративную систему.

Браузер: звук и понятное состояние

Браузер отправляет микрофон и воспроизводит обратный трек. В отдельном событийном канале он видит текущие session/turn IDs, распознанный текст, источник ответа, отмену и деградацию. Локальные NATS WS можно сохранить на первом шаге, но credentials должны быть с узкими правами. Позже application WSS gateway может скрыть broker от браузера и проверять доступ к сессии.

На схеме первые два блока находятся на одном клиентском устройстве. Для браузера сохраняем его встроенную обработку. Sonora предлагаем как альтернативу для нативного клиента, не как второй обязательный фильтр после browser AEC. Возвратная стрелка в AEC означает локальную копию реально проигрываемого PCM и его задержку, а не повторную отправку TTS на ASR.

Core: медиа, согласование формата и границы жизни

Core владеет peer connection, аудиочасами, bounded queues и ресемплингом. Он переводит WebRTC в собственный ASR контракт и ответ TTS обратно в WebRTC. Бизнес-сценарий остаётся в Agent: не надо переносить туда aiortc, а в Core - prompts и права tools. Локальный брокер соединяет workers, но не делает их автоматически независимыми от центральных моделей.

Опциональное подключение к основной сети строится позже как явно разрешённый adapter. Его отказ не должен менять local-only сценарий. В строгом offline profile fallback наружу запрещён. Можно синхронизировать выбранные обезличенные события, когда сеть снова появилась, но модельный контекст и голос не должны уходить туда без отдельной политики.

К началу главы

09Звук на клиенте: Sonora и проверка Opus

Sonora: предлагаемая обработка до отправки

Opus сжимает звук для сети. AEC убирает из микрофона ответ, который звучит в динамиках; NS подавляет шум, AGC регулирует усиление. В CLI 0.156.1 Sonora включена внутри voice-host. Обработчик получает PCM микрофона и копию воспроизводимого звука с задержкой, обрабатывает блоки по 10 мс при 48 кГц mono и собирает Opus-пакеты по 20 мс.

У нас startMic уже запрашивает браузерные AEC/NS; defaults включены. Сначала сохраняем в диагностике фактические track.getSettings() исходного микрофона. Sonora 0.2.0 включаем в список улучшений как прототип нативного клиента. Она работает локально, не требует ChatGPT или внешней модели. Браузерная интеграция потребует отдельного прототипа: готовое подключение WASM/AudioWorklet здесь не подтверждено. Возможности и лицензия BSD-3-Clause описаны в документации Sonora.

Opus: не добавлять заново, а проверить соединение

Мы используем browser WebRTC и aiortc 1.14.0, в котором Opus уже поддерживается и стоит первым в audio codecs. Это не доказывает выбор кодека в живом соединении. В исходниках собственного принудительного выбора Opus не найдено. Проверяем оба направления и отличаем SDP-предложение от фактически используемого codecId.

// Пример для будущей диагностики рядом с connectSession, не внедрённый код.
// micTrack - исходный микрофон до replaceTrack/VAD, peer - текущий peer connection.
console.log("Параметры микрофона", micTrack.getSettings());
const report = await peer.getStats(); // Читаем статистику уже работающего соединения.
for (const stream of report.values()) {
  // Смотрим только локальные отчёты об отправленном или полученном аудио.
  if (!["outbound-rtp", "inbound-rtp"].includes(stream.type)) continue;
  if ((stream.kind ?? stream.mediaType) !== "audio" || stream.isRemote) continue;
  const codec = report.get(stream.codecId); // Связываем поток с его кодеком.
  const packets = stream.type === "outbound-rtp" ? stream.packetsSent : stream.packetsReceived;
  console.log("Поток и кодек", stream.id, packets ?? "неизвестно", codec?.mimeType ?? "неизвестно");
  // Полный отчёт нужен для clockRate/channels/fmtp и доступных метрик сети.
  // Повторный снимок покажет активность; этот вывод не измеряет качество AEC.
}

Опоры для параметров: RFC 7587 и W3C WebRTC Stats. Обработка Sonora и Opus выполняется без внешних сервисов, но независимость всей системы всё равно требует локальных ASR/LLM/TTS и сетевой приёмки.

К началу главы

10Как очищается звук у нас, в CLI и в Desktop

В выдержке из бокового чата верно разделены Silero и Sonora. Но наш путь содержит ещё один этап: до отправки звука браузер может пропустить его через energy gate. Поэтому сравниваем не названия библиотек, а последовательность обработки и то, что остаётся на выходе каждого этапа.

AEC удаляет акустическое эхо ответа из микрофона, NS уменьшает шум, AGC регулирует уровень. Gate закрывает сигнал ниже порога, а VAD находит участки речи. Opus решает транспортную задачу: сжимает звук. Эти механизмы не взаимозаменяемы; Silero можно сохранить после Sonora или browser AEC/NS.

У нас: AEC и NS запрашиваются на стороне браузера

startMic передаёт два флага из audio state в getUserMedia. Они включены в defaults, но браузер и устройство могут обработать запрос по-разному. В просмотренном коде нет отдельного вызова Sonora, RNNoise или SpeexDSP в этой точке. На выходе - MediaStream, уже после запрошенной браузерной обработки. Снять настройки нужно у исходного микрофонного трека, до замены его треком Web Audio.

// Фрагмент параметров startMic. Это запрос обработки, а не замер качества.
const stream = await navigator.mediaDevices.getUserMedia({
  audio: {
    echoCancellation: state.echoCancellation, // Просим убрать эхо динамиков.
    noiseSuppression: state.noiseSuppression, // Просим уменьшить шум.
  },
  video: false, // Видео для этого захвата не нужно.
});
// autoGainControl здесь явно не задан; нельзя считать его выключенным.

Energy gate: тихий сигнал закрывается, речь не очищается

Если gate включён, connectSession вызывает createEnergyVad и заменяет sender track. Web Audio оценивает RMS - среднеквадратичный уровень сигнала - и переводит его в dB. Выше порога gain стремится к 1, ниже - к 0; переключение сглаживается attack/release. Это не нейросетевое выделение голоса и не AGC: во время открытого gate шум внутри речи может пройти вместе с ней. Тихие начала и окончания слов могут пропасть до Silero.

// Смысл участка createEnergyVad; получение RMS/dB опущено.
const active = db > gate; // Порог сравнивается с общей энергией, не смыслом речи.
const target = active ? 1.0 : 0.0; // Пропускаем либо закрываем весь сигнал.
gainNode.gain.setTargetAtTime(target, ctx.currentTime, T); // Сглаживаем переход.
// Это gain 0/1, а не восстановление речи из смеси с шумом.

Core меняет формат аудио, а не устраняет эхо

WebRTC доставляет закодированное медиа; aiortc декодирует его. TrackSourceNode приводит аудио к mono PCM16LE 16 кГц и кадрам по 20 мс, WhisperStreamNode добавляет метаданные и публикует в NATS. Название normalization здесь относится к формату и длительности кадров. В этом коде не найден процессор очистки или автоматического выравнивания громкости. Детальный бинарный пример находится в главе о кадре NATS.

Silero выбирает фразы из накопленного PCM

На стороне ASR bridge _get_timestamps вызывает ONNX VAD и получает start/end. Затем код берёт audio[start_sample:end_sample] из исходной записи. Silero не возвращает заменённую очищенную волну: выбираются участки того же звука. Именно их bridge упаковывает в WAV и отправляет в HTTP ASR. Это соответствует контракту Silero VAD.

# Фрагмент существующего выделения фразы по интервалам VAD.
segment_audio = audio[start_sample:end_sample] # Берём исходные сэмплы речи.
# Далее bridge пишет этот сегмент в WAV и отправляет распознавателю.
# Denoised audio от Silero этот участок не получает.

Для изолированной поставки важна ещё загрузка VAD: при отсутствии ONNX-файла _ensure_vad_loaded может скачать модель. Её нужно включить в поставку с контрольной суммой и лицензией, проверить локальный путь и cold start с запрещённой внешней сетью. Silero оставляем и при добавлении Sonora; перенос сегментации и очистки в один блок только запутает диагностику.

Вернуться к схеме нашего тракта

CLI: обработка находится в voice-host перед Opus

В CLI 0.156.1 микрофон обслуживает helper, а не UI терминала или app-server. Processor::new включает в Sonora эхоподавление, шумоподавление и адаптивную цифровую регулировку усиления. Capture обрабатывается блоками по 10 мс при 48 кГц mono; затем собирается 20-мс пакет Opus. По сети идёт кодированное медиа, не ONNX VAD и не файл WAV. Никакой внешний API для самого Sonora-процессора не нужен.

Почему CLI передаёт в AEC ещё и проигранный ответ

render_output сохраняет реально проигранные сэмплы и временные данные. Capture worker сначала подаёт reference в процессор, затем обрабатывает микрофон; это позволяет сопоставить ответ из динамиков с его эхом. После mute или разрыва обработка сбрасывается, чтобы не использовать старую опору. Поставить Sonora на сервер только после получения PCM не равно этому пути: без синхронизированного render reference там нет сведений о реальном воспроизведении у пользователя.

App-server управляет сеансом, signaling, событиями и агентом. В этом V3-пути он не выполняет capture DSP и не несёт Opus между устройством и сервисом. Подробности - в архитектурном сравнении. В upstream есть синтетический тест влияния reference; здесь он не запускался и не заменяет акустический стенд.

Вернуться к схеме CLI

Desktop Codex voice: собственный web provider с NS

В просмотренном provider Wbo содержит channelCount:1 и noiseSuppression:true. Класс Gbo открывает MediaStream, использует Web Audio/AudioWorklet для буферизации и mute и отдаёт трек WebRTC. В этом участке AEC и AGC явно не заданы; нельзя дописать из этого, что браузер их выключил. Отдельный процессор Sonora в этой ветке не подтверждён.

// Дословные поля provider из минифицированного бандла; оформление раскрыто.
const Wbo = { channelCount: 1, noiseSuppression: true };
// Gbo передаёт параметры в захват и строит трек Web Audio для WebRTC.
// Здесь нет явного echoCancellation или autoGainControl.

Desktop ChatGPT voice: AEC зависит от policy, результат читается из трека

Другой голосовой путь использует функцию, которая при device policy nowhere возвращает пустой объект, иначе - echoCancellation:true. Пустой объект не означает запрет AEC. Код создания сессии читает getSettings().echoCancellation и записывает наблюдаемое значение в состояние. Для текущего устройства это значение здесь не снято. NS и AGC в этом фрагменте не заданы явно, а возможная native/provider ветка имеет отдельные условия.

// Смысл rt(device): точная минифицированная строка сохранена в evidence JSON.
const constraints = policy === "nowhere" ? {} : { echoCancellation: true };
// Пустой объект оставляет настройки реализации, а не принудительно выключает AEC.
const { echoCancellation } = microphoneTrack.getSettings(); // Наблюдаемое значение.
// Отсутствующий параметр нужно обозначать неизвестным, не заменять false.

Ducking уменьшает громкость ответа, но не очищает запись

В updateDucking при активности пользователя уменьшается playback volume; после паузы громкость восстанавливается. Монитор активности может использовать energy/Silero-ветку. Пользователю проще говорить поверх ответа, а эхо может стать тише. Но ducking не вычитает шум и эхо из микрофонных сэмплов. Это управление воспроизведением рядом с AEC, не его замена. Наличие Silero в таком мониторе не означает одинаковую с нашим ASR bridge сегментацию.

Диктовка Desktop не запускает тот же voice processor

У диктовки отдельный recorder/streaming adapter. В бандле есть выбор native microphoneCapture и browser capture; в просмотренном browser-вызове явно задаётся mono. Дальше адаптер отправляет запись или аудиопоток удалённому STT и получает текст. Этот код не доказывает Sonora, полный набор AEC/NS/AGC, обработку native capture или очистку внутри закрытого сервиса. Кнопку микрофона нельзя описывать как тот же путь, что разговор или CLI /voice.

Сохранённые фрагменты Desktop с SHA256 и byte offsets позволяют проверить эти выводы без абсолютных путей к компьютеру. Там только код обработки звука; credentials и пользовательские реплики не включены. Названия минифицированных функций относятся к этому бандлу и изменятся при пересборке.

Вернуться к схеме Desktop

Какие альтернативы сравнивать и что измерять

Для существующего браузерного клиента сначала проверяем встроенную обработку, gate и Opus. Для собственного native клиента начинаем с Sonora, поскольку в Codex виден пример всей цепочки capture/render. Остальные варианты нужны для сравнительного стенда, а не для автоматического включения всех фильтров подряд.

Одинаковый стенд должен включать обычную и тихую речь, фоновый шум, только ответ из динамиков и одновременную речь собеседника с ответом. Сравниваем WER, потерянные границы VAD, ложные перебивания, остаточное эхо, clipping, задержку и CPU. Остаточное эхо сначала измеряем при молчащем пользователе; double-talk оцениваем отдельно, чтобы не принять подавленную живую речь за хорошее AEC. Ни Sonora, ни другая библиотека ещё не показали у нас выигрыш; цели и порядок внедрения приведены в плане работ.

К началу главы

11STT: сначала управляем фразой, потом решаем, нужен ли streaming

У текущего bridge уже есть Silero VAD, phrase_id, pending и финальный текст. Это сохраняем. Первое изменение - локальный ASR provider с тем же HTTP-контрактом, заранее поставленными весами и явной readiness. Затем измеряем, сколько времени занимает ожидание границы фразы отдельно от распознавания.

Цель в 500 мс - кандидат для будущего испытания, не утверждение о доступной нам модели. Если локальный ASR распознаёт только после конца фразы и этого хватает пользователю, streaming можно не добавлять. Файловый режим полезен для больших записей, но его очередь и таймауты отделяем от разговорных.

К началу главы

12TTS: подключаем недостающую половину разговора

Первый рабочий шаг - озвучить подтверждённый ответ сценария своим TTS и отправить его по обратному WebRTC-треку. Сначала можно синтезировать целую короткую реплику. Потоковая генерация и синтез предложениями появляются позже, когда есть cancellation, порядок chunks и контроль того, что пользователь действительно услышал.

# Предложение собственного интерфейса, не существующий endpoint проекта.
job = {"session_id": "s-1", "turn_id": "t-1", "response_id": "r-1",
       "generation": 4, "text": "Найден один аэропорт.", "voice": "ru-local"}
# TTS выдаёт сэмплы в своём формате, например PCM16LE mono 22050 Гц.
# Voice Gateway ресемплирует их, задаёт монотонный PTS и кодирует в Opus.
# RTP-clock Opus = 48000; он не объявляет исходные сэмплы TTS как 48000 Гц.
# Каждый chunk несёт response_id, generation и seq; отменённые chunks удаляются.

Цель первой реализации: для 100 коротких ответов text→decoded audio завершается 100/100 раз, у каждого ответ и waveform имеют один response_id. После отмены удаляем ещё не отправленный хвост и не принимаем новые chunks старого ответа. Уже отправленные RTP пакеты и буфер браузера отозвать нельзя; слышимый хвост измеряем отдельно. Затем проверяем p95 first audio, RTF TTS и задержку перебивания. Наличие WAV и успешный decode - необходимые проверки, но качество произношения и слышимость проверяются отдельно.

К началу главы

13Перебивание, mute и Stop - три разных действия

Сейчас Core на время запроса агента публикует voice blocked, а frontend выключает sender.track. Такой полудуплексный режим не даёт пользователю перебить работу голосом. Его можно оставить как явный fallback, но для разговорного режима микрофон остаётся активным, а новая речь отменяет старый ответ.

# Предлагаемая защита от ответа предыдущего хода.
generation += 1
old_turn.cancel()       # Отменяем вычисления, которые действительно поддерживают отмену.
playback_queue.clear() # Убираем ещё не услышанное аудио.
# Сетевой callback со старой generation завершается без показа и воспроизведения.
if chunk_generation != generation:
    return

Демо WebRTC из предыдущей работы уже использует epoch и очистку входной очереди на mute. Это полезный образец, но не готовый production barge-in: там нет полноценного AEC и агентные delegation requests отклоняются. После перебивания в историю должен попасть факт, что часть озвучки не была услышана. Иначе следующий ответ опирается на реплику, которую пользователь пропустил.

К началу главы

14Ограничиваем не только очередь, но и задачи, байты и возраст аудио

В FanOutNode.subscribe стоит asyncio.Queue() без maxsize. Ветка drop-oldest есть, но QueueFull у такой очереди не возникнет. В WhisperStreamNode.handle_frame каждый кадр создаёт task, которая затем ждёт semaphore. Значение 3 ограничивает одновременно выполняемые publish, но не накопленные task.

{
  "frames": 100,
  "queue_maxsize": 0,
  "queued_frames": 100,
  "pending_publish_tasks": 100,
  "publish_calls_entered": 3,
  "network_requests": 0
}

Проба доказывает механизм роста, а не утечку или падение production. После восстановления потребителя очередь может уйти; время восстановления и рост памяти на реальной нагрузке ещё не измерены. Остановившийся потребитель способен оставить память пропорционально длине ожидания, поэтому одного semaphore недостаточно.

# Запустить из корня webrtc-komaroff в окружении с numpy, av и nats-py.
# --source-root указывает на исследуемый checkout; сеть не используется.
python3 DOCS/codex-voice-comparison-2026-10-02/probe_audio_bounds.py --source-root .

Прямая экономия от лимита - ограниченное число удерживаемых кадров и задач, а не гарантированное ускорение ASR. В качестве исходной политики 200 мс годятся для разговора, но её надо проверить на packet loss и точности. Для обязательной полной записи сбрасывать кадры нельзя: нужна остановка с ошибкой либо иной надёжный канал.

К началу главы

15События сессии: из ответа целиком в наблюдаемый жизненный цикл

Сейчас есть trace envelope между сервисами и часть событий содержит session_id. Но browser подписан на общий events subject, а handleNatsPayload передаёт событие обработчику без единого фильтра активной сессии. Для двух окон или двух разговоров одного пользователя это граница, которую надо проверить. UUID сессии в payload ещё не является авторизацией.

{
  "schema_version": 1,
  "event_id": "e-42",
  "session_id": "s-1",
  "call_id": "c-2",
  "turn_id": "t-3",
  "response_id": "r-4",
  "generation": 7,
  "seq": 42,
  "type": "tts.started",
  "ts_ms": 1790899200000,
  "payload": {"voice": "ru-local", "sample_rate": 22050, "channels": 1}
}

Состояния удобно держать раздельно: соединение connecting/connected/closed, вход listening/muted, работа transcribing/thinking/tool_running/speaking/cancelling. Mute и speaking могут быть одновременно, поэтому одна линейная строка статуса на всё будет давать ложные переходы. UI показывает наблюдаемое состояние, а не считает HTTP 200 доказательством слышимого ответа.

При reconnect клиент просит snapshot + события после cursor. Для media потерянное время не воспроизводится; для завершённых результатов допустим replay. Цель: в двух одновременных сессиях ни одного чужого сообщения/voice block; после reconnect - snapshot без дублирования финального ответа. Core NATS не хранит события для отсутствующего подписчика, это надо обеспечить на уровне приложения или отдельного durable stream.

К началу главы

16Сохранение хода, повтор запроса и права инструментов

В свежем main runtime_state и история сохраняются в одной транзакции. Тесты также подтверждают, что обычная ошибка сохранения не повторяет workflow. Но конфликт версии состояния ещё вызывает повтор workflow, а tool мог успеть выполнить действие до SQL commit. Для голоса с reconnect и повтором фразы это особенно чувствительно.

В этом месте полезна идея Codex handoff: голосовой канал отдаёт агенту конкретную задачу и получает конкретный результат, сохраняя связь идентификаторов. Копировать терминал и unrestricted shell не надо. Нужны только доменные инструменты площадки с собственной проверкой прав и сроком жизни запроса.

К началу главы

17Локальные модели: совместимость интерфейса не гарантирует качество

В проекте уже два пути LLM: llama.cpp внутри процесса и Ollama через HTTP. Ollama можно поставить в той же изолированной сети. Для CPU-площадки GGUF путь полезен, но текущий init не содержит явной настройки GPU layers; установка GPU сама по себе не доказывает ускорение этого adapter.

Выбор конкретной ASR/LLM/TTS модели стоит сделать по одному русскому набору: тихая речь, имена аэропортов, номера рейсов, паузы, шум и попытки вызвать недопустимый инструмент. Без такого сравнения нельзя обосновать, что меньшая модель даст тот же результат быстрее. Ускорение измеряем на одном железе и одной нагрузке, качество - отдельно от синтаксической валидности JSON.

К началу главы

18Что можно переносить как код, а что только как приём

Совпадение архитектурной идеи не требует копирования большого куска Codex. Для нашего Python/TypeScript проекта дешевле собственный небольшой interface и тесты, чем зависимость от всего Rust-ядра с облачным разговорным контрактом. Перед переносом файлов отдельно проверить лицензии исходников, пакетов, весов и конкретного голоса.

LiveKit/SFU не включаю в обязательный первый этап. Сейчас разговор один-на-один с сервером; aiortc уже используется. Рассматривать смену transport runtime стоит после проблем распределения peers, TURN эксплуатации или измеренной нагрузки. Новый framework добавит серверы, зависимости и offline packaging; само его имя не уменьшает latency модели.

К началу главы

19Какими числами проверяем пользу изменений

Базовая единица замера - один законченный пользовательский ход в конкретной сессии. Отдельно пишем длительность аудио, размер моделей/quantization, версии, CPU/GPU/RAM, число клиентов, сеть и cold/warm режим. Сравниваем одинаковые входы. Тест на наушниках не заменяет тест AEC с динамиками.

// Пример чтения медиаметрик в месте, где приложение владеет RTCPeerConnection.
// Это не готовая команда для браузерной консоли: pc берётся из кода приложения.
const report = await pc.getStats();
for (const item of report.values()) {
  // Счётчики RTP и jitter относятся к медиа; их недостаточно для ASR latency.
  if (item.type === "inbound-rtp" && item.kind === "audio") {
    console.log({packetsReceived: item.packetsReceived,
                 packetsLost: item.packetsLost, jitter: item.jitter});
  }
}

Сумма p95 отдельных этапов не равна p95 всей цепочки. Общую задержку измеряем непосредственно. При отсутствии синхронизации часов межпроцессная разность ts_ms может быть неверной; используем связанные spans, локальные monotonic интервалы и отмечаем точность clock sync. Рост RTP counters ещё не доказывает качество распознавания или полный слышимый ответ.

К началу главы

20Испытания: от контракта до холодного старта без сети

Для сравнения достаточно локальных тестов; сегодня они не доказывают работу всего стенда. Будущую приёмку проводим в отдельном namespace/VM площадки, а не отключением сети на рабочей машине. Любые firewall/netem изменения относятся к будущему стенду и в этом исследовании не выполнялись.

Негативные тесты должны показать точную границу отказа: parser, ASR provider, Agent, TTS или media. Для load-теста увеличиваем число сессий, пока хотя бы один критерий не нарушится; последняя успешная нагрузка становится подтверждённым N_accept. Команду "docker compose up" нельзя объявить проверкой полной автономности.

К началу главы

21Порядок работ: сначала автономность и ограничения, затем разговор

Менять транспорт, модель, схему сессии и workflow сразу неудобно: при регрессии непонятно, где искать причину. Ниже этапы, после каждого остаётся рабочий режим. Это проект изменений, не внесённые этим документом изменения приложения.

Приоритетный набор для первой доработки: автономный профиль, bounded работа и локальная озвучка. Они закрывают зависимость от основной сети, предел ресурсов и отсутствие аудиоответа. Streaming и новая библиотека WebRTC могут быть следующими решениями, но только если измеренный сценарий этого требует.

К началу главы

22Куда идти в коде за каждым блоком схемы

Ссылки на webrtc-komaroff закреплены на GitLab main 1fc1702, а не на старом локальном checkout. В каждой записи указаны вход, результат и граница ответственности. Ссылки на незакоммиченные аудиодемо ведут в соседний локальный checkout; для чтения самого учебника этот каталог не нужен.

Browser: connectSession → negotiate

Вход - пользователь включает микрофон. connectSession открывает MediaStream, создаёт peer, назначает sender и при необходимости energy gate. negotiate собирает SDP и вызывает /core/offer. Выход - session_id и peer; при отказе signaling свежий main закрывает открытые ресурсы.

Core: offer → handle_track → AudioGraph

handle_offer_connect создаёт peer и UUID сессии; incoming audio запускает handle_track. Source нормализует звук, WhisperStreamNode упаковывает кадры и подписывается на текст. Выход - PCM через NATS и последующий agent request; TTS producer в этом графе не назначен.

# Выборочное дерево вызовов, не временная диаграмма.
POST /core/offer
  handle_offer → handle_offer_connect
    _webrtc_pc_create → aiortc.RTCPeerConnection
    on_track → handle_track
      AudioGraph → TrackSourceNode._normalized_chunk_stream
        WhisperStreamNode.handle_frame → _publish → NATS
      _handle_whisper_message → handle_transcription
        NATS request nats.agent.<user>

Bridge: кадры → VAD → WAV → HTTP

_process_message разбирает wire packet; _handle_frame накапливает сэмплы; VAD выбирает сегменты; _transcribe_and_publish пишет временный WAV, ждёт слот и вызывает transcribe_http_text. После обработки WAV удаляется в finally. Это не доказательство удаления всех данных сервера LinTO или журналов.

Agent: входной текст → workflow → result/UI

AgentServer.handle_request валидирует AgentInboundRequest, запускает runner и публикует UI события. Runner передаёт сценарную работу выбранному workflow через NATS, сохраняет состояние и историю, возвращает typed response. Голосовые identifiers полезны для корреляции, но нынешняя обработка остаётся текстовой.

Postgres: атомарное состояние и история

Свежий runner использует одну db.transaction() и передаёт один connection в save_runtime_state и persist_chat_turn. Это защищает два SQL эффекта вместе. Outbox, lease и идемпотентность внешних tools остаются отдельными предложениями.

LLM: local и HTTP - способы вызова, а не география

Local adapter вызывает llama.cpp; HTTP adapter делает Ollama POST /api/chat. Оба возвращают JSON message без потоковой озвучки. Локальный model downloader умеет использовать уже существующий путь; при отсутствии веса обращается к Hugging Face. Offline профиль обязан выбирать конкретный файл и проверять его наличие.

Codex: управление разговором и helper

TUI вызывает thread/realtime/start с WebRTC transport. RealtimeCallClient создаёт удалённый call; core ведёт session/events и handoff. voice-host владеет медиасоединением. Код сервера, выполняющего распознавание и генерацию аудио, здесь отсутствует; для него подтверждены клиентский контракт и исторические наблюдения, не внутреннее устройство.

Локальный Processor::new включает Sonora AEC/NS/AGC; render_output сохраняет реально воспроизводимые сэмплы, CaptureWorker передаёт их в обработчик перед capture. Это дополнение к исследованию транспорта, не функция app-server. Подробности и план переноса - в разделе Sonora, проверка кодека - в разделе Opus.

Реестр исходников

К началу главы

23Что подтверждено, что предложено и чего пока не знаем

VERIFIED / SOURCE означает, что связь найдена в коде или конфигурации. LOCAL TEST - что конкретная проверка выполнена без живых сервисов. INFERRED - механизм риска или ожидаемый эффект без нужного замера. PROPOSED - проект изменения. UNKNOWN - сведений недостаточно. Эти статусы не превращаются в production evidence от наличия хорошей схемы.

Какие проверки выполнены в этой работе

Из remote main извлечена временная копия только нужных исходников; рабочая папка не переключалась. В отдельном venv установлены test requirements. Выполнены python -m unittest discover -s tests -v: 13/13 passed (3 persistence, 3 ICE, 7 routing). После подготовки зависимостей frontend vitest run: 1/1 passed, cleanup при отказе signaling. Модели не запускались, в тестах нет живого ASR/LLM/NATS.

Проба очередей импортирует настоящие классы Core и заменяет только publish ожидающим mock. Получены queue size=100, pending tasks=100, publish entered=3; network requests=0. Это отдельное доказательство роста незавершённой работы, а не тест качества звука.

Выполнены 12 статических проверок HTML и 8 тестов навигационного JS на mock DOM. Проверены внутренние anchors, ссылки схем, меню всех разделов, JSON-примеры, относительные ссылки и отсутствие сетевых загрузок. SVG отдельно отрисованы через ffmpeg/librsvg: это проверка схем, не всей страницы.

Дополнение Sonora/Opus и сравнение очистки проверены отдельно: 11 тестов пояснений, evidence, ссылок схем и краткости выжимки. Пример getStats исполнен на фиктивных потоках в обе стороны, включая неизвестный кодек. Пересобраны 9 SVG учебника и выжимки, просмотрены пять новых или изменённых схем. Микрофон, реальные RTP и обработка Sonora в этих тестах не запускались.

Пять сохранённых Desktop-фрагментов сверены непосредственно с локальным ASAR: версия package.json, SHA256 трёх бандлов, byte offsets и связанные фрагменты совпали. Данные входа не читались. Эта проверка подтверждает источник текста, но не настройку текущего устройства и не качество удаления эха.

Браузер отклонил открытие file:// по политике окружения. Обход через HTTP-сервер или headless browser не выполнялся. Поэтому реальный UI, мобильная раскладка, печать и клавиатурная навигация в браузере остаются непроверенными. Полный протокол - в verification.json; повторяемые команды - в README.txt.

Что требует отдельного стенда

Не проверены deployed SHA/images и live DRS, фактический selected ICE pair/codec, реальное качество ASR/TTS, RTF моделей на целевой CPU/GPU, AEC при перебивании, end-to-end задержки, конкурентные сессии и полностью offline cold start. Также не установлен внутренний STT/TTS стек ChatGPT. Для утверждения автономности нужен весь комплект локальных зависимостей и сетевой тест, а не только source review.

К началу главы

24Проверяем понимание и переходим к реализации

Начать можно с двух независимых результатов: комплект для cold start без основной сети и ограниченные очереди на существующем transport. Затем локальный TTS закрывает аудиоответ. Когда эти части проверены, имеет смысл доводить полнодуплексный разговор, а не заменять весь проект ради сходства с ChatGPT.

Связанные проектные документы: текущая архитектура, NATS контракты, точки входа. Предыдущая работа: аудиоучебник Codex в соседнем checkout. Его ссылки необязательны для открытия этого автономного HTML.

Официальные источники для протоколов

Роли app-server и lifecycle операций: OpenAI app-server. Характер Core NATS и необходимость отдельного хранения завершённых событий: NATS Core. Opus RTP-clock 48 кГц при разных частотах входа: RFC 7587. Peer и getStats: W3C WebRTC. Условия доступа к микрофону: MDN getUserMedia. Ссылки не загружаются автоматически и не являются runtime dependencies учебника.

К началу главы