От микрофона до агента

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

Голосовой интерфейс не выбирает один универсальный API. Диктовка возвращает текст, озвучка возвращает звук, а разговор держит двусторонний сеанс. В Codex и в webrtc-komaroff эти задачи соединены разными способами. Здесь обе реализации разобраны в одном учебнике, вместе с демо, исходниками и результатами диагностики.

Сначала отделяем звук от управления. Затем разбираем форматы и воспроизводимые примеры Codex, переходим к нашему Core и NATS, проверяем подключение и только после этого обсуждаем точность распознавания. Такой порядок помогает не лечить модель, когда до неё ещё не дошёл ни один аудиокадр.

Микрофон отдаёт отсчёты звука. Клиент очищает и кодирует их, а WebRTC доставляет медиа собеседнику. Управляющие каналы создают сеанс и передают события. NATS в нашей реализации дополнительно переносит декодированное аудио между Core и ASR bridge. У каждого перехода свой контракт, и успех одного канала ничего не говорит о готовности соседнего.

Как читать без прыжков между книгами

Что означает отметка проверки

SOURCE - связь найдена в закреплённом коде; RUNTIME - поведение наблюдали в названной пробе; INFERRED - объяснение следует из наблюдений, но точный узел отказа ещё не установлен; PROPOSED - предлагаемое изменение. Исторический успех API не обещает доступ тому же аккаунту сегодня. Улучшения ниже не внедрялись при сборке этой книги.

Читать можно без сети. Ссылки на наши файлы и исходники относительные и остаются внутри комплекта. Ссылки на RFC, GitHub и GitLab - дополнительные первоисточники; переход к ним требует сети. В архиве нет входа пользователя, cookies, личных аудиозаписей, моделей или установленного Desktop.

Приёмка этой объединённой редакции: ссылки, повторная сборка, тесты и ограничение браузерного просмотра. Исторические отчёты отдельных демо остаются в своих главах.

Переносимый комплект: подготовка и запуск. Ссылки и код рядом с этим файлом; команды выполняются из корня после подключения scripts/audio-textbook/env.sh. Вход и модели не входят в архив.

Helper - локальный помощник, который обслуживает звук. App-server управляет разговором и событиями Codex. По WebRTC передаётся звук, по HTTPS/WSS - управление и текстовые события. SDP описывает соединение, а не аудиозапись; подробности дальше в форматах и словаре.

Куда идти дальше

Для готовой записи начните с /transcribe или PCM Realtime STT. Для чтения своего текста есть HTTP pronunciation, GA Realtime, appendSpeech и локальные движки. Сохранённый ChatGPT-ответ читается через /synthesize. Самостоятельный разговор собран в WebRTC /voice. У каждого способа своя глава, команда и доказательный статус.

Отказы Speech429, summary404 и непроверенные режимы вынесены отдельно. Сравнение wire форматов не обещает обход распознавания клиента.

Открыть карту: где и как вызываются все способы

Маленький микрофон превращает речь в текст. Разговор создаёт отдельный realtime-сеанс. Штатный ChatGPT Read Aloud запрашивает аудио по ID ответа, а Linux-кнопка расширения передаёт сам текст выбранному backend. Для GA Realtime и самостоятельных демо кнопки в Desktop нет: контракт задаёт команда запуска.

Снимки микрофона получены. Read Aloud, настройки и экран разговора описаны по коду, но не сняты из установленного Community. Сетевые успешные пробы не подменяют GUI-проверку.

# Выполняйте из корня распакованного комплекта.
source ./scripts/audio-textbook/env.sh
repo="$AUDIO_ROOT"
audio_out="$(mktemp -d "$audio_out/codex-audio-ui.XXXXXX")"
python3 "$repo/scripts/tts-demos/http-tts.py" chatgpt-text   "$audio_out/voice.mp3" --text-file "$repo/scripts/tts-demos/sample-ru.txt" --dry-run --auth-file "$auth_file"

Удалось снять поле ввода и его кнопки. Снимки разговора, меню удалённого Read Aloud, кнопки Linux Read Aloud и её настроек в этом проходе не получены. Ниже их положение описано по коду; нарисованных "скриншотов" вместо них нет. Рабочий сетевой контракт и видимость кнопки в конкретном экземпляре - разные проверки.

1. Микрофон: записать речь в поле ввода

Нажимаете маленький микрофон справа от названия модели, произносите текст и завершаете запись. Результат появляется в поле ввода; это диктовка, а не разговор с аудиоответом. В проверенном бандле PPc → FPc → startDictation выбирает запись и способ отправки.

Потоковая ветка включается только при разрешённом streaming и отсутствии явно заданного языка: C && ge.current == null. Она получает connect-info, передаёт PCM16 mono с указанной фактической частотой AudioContext и принимает текст. При невозможности начать или завершить поток предусмотрена файловая транскрипция. У прикреплённого аудиофайла streamingSession: null, поэтому это сразу файловый путь.

Файловая ветка Fki отправляет multipart с file и, при наличии, language на POST /transcribe. В ChatGPT-контексте HPc добавляет идентификаторы записи, попытки и сообщения. Контейнер зависит от записывающего клиента: файл FLAC в нашем примере не доказывает, что Desktop записывает микрофон в FLAC. Распознаёт удалённый сервер; исходники серверной STT нам недоступны.

Фрагмент проверенного Desktop-бандла

webview/assets/app-initial-41d268a90bf8.js · смещение 10426510 символов · 30.09.2026. Это выдержка из минифицированного кода, не самостоятельный скрипт.

Копировать

Выдержка JavaScript клиента. Это не Rust и не готовый самостоятельный скрипт.

// Обработчик выбирает потоковую диктовку, если она разрешена и сеанс ещё не подготовлен.
// Комментарии добавлены для учебника; minified-выдержка может быть неполной.
let t=C&&ge.current==null;if(l.timings!=null&&(l.timings.streamingAttempted=t),le.current=null,F(!1),w!==`composer`&&Oe(),t){let e=Ce();try{d=r.prepareStreaming(`composer`,l.performance,e.onTranscriptUpdate==null?void 0:(t,n)=>{oe.current!==`abort`&&e.onTranscriptUpdate?.(t,n)},n.chatgpt==null?void 0:{dictationSessionId:l.dictationSessionId,attemptId:l.attemptId,finishTimeoutMs:6e4}),re.current=d}catch(e){let t=e;d?.close(),d=null,Jd.warning(`[Composer] unable to prepare streaming dictation`,{safe:{},sensitive:{error:t}})}}n.chatgpt;let i=!1,c=d!=null,p=IPc,m=await r.start(()=>{i=!0,c=!1,p()});u=!0;let h=performance.now();if(d!=null&&re.current!==d&&(d=null),f())return;l.

Фрагмент проверенного Desktop-бандла

webview/assets/app-initial-41d268a90bf8.js · смещение 4053407 символов · 30.09.2026. Это выдержка из минифицированного кода, не самостоятельный скрипт.

Копировать

Выдержка JavaScript клиента. Это не Rust и не готовый самостоятельный скрипт.

// Запрос получает сведения для соединения диктовки; session.start отдельно задаёт PCM и VAD.
// Комментарии добавлены для учебника; minified-выдержка может быть неполной.
async function tti(){return(await ol.getInstance().post(`/codex/dictation-stream-connect-info`,void 0)).body}function nti(){return(nti=e((()=>{vs()})))()}function rti(e,t,n){return{type:`session.start`,dictation_session_id:n.dictationSessionId,attempt_id:n.attemptId,config:{language:n.language,input_audio_format:`pcm16`,sample_rate_hz:e,num_channels:1,max_buffer_size_bytes:4194304,max_utterance_duration_ms:3e4,session_ttl_ms:3e5,provider_mode:`streaming_sse`,transcript_delivery_mode:t?`segment`:`final_only`,vad:{type:`server_vad`,threshold:.5,prefix_padding_ms:300,silence_duration_ms:500}}}}function iti(e,t){return e.reason.length>0?new aU(t?`Dictation stream closed with reason '${e.reason}' and code ${e.code}.`:`Dictation stream closed before session.start completed with reason '${e.reason}' and code ${e.cod

Фрагмент проверенного Desktop-бандла

webview/assets/app-initial-41d268a90bf8.js · смещение 4596422 символов · 30.09.2026. Это выдержка из минифицированного кода, не самостоятельный скрипт.

Копировать

Выдержка JavaScript клиента. Это не Rust и не готовый самостоятельный скрипт.

// Файловый STT собирает multipart с исходным Blob, MIME и именем, затем вызывает /transcribe.
// Комментарии добавлены для учебника; minified-выдержка может быть неполной.
async function Fki(e,t={}){let n=t.contentType??(e.type&&e.type.trim().length>0?e.type:`audio/webm`),r=n.split(/[/;]/)[1]??`webm`,i=zki(t.filename??`codex.${r}`),a={language:t.language},o=Bki(),s=await Rki({blob:e,boundary:o,filename:i,contentType:n,fields:a});return Lki(()=>ol.getInstance().fetch(`/transcribe`,{method:`POST`,body:s,headers:{"Content-Type":`multipart/form-data; boundary=${o}`,...Mo()},signal:t.signal,retry:!1}).then(e=>e.json()).then(Iki),t.signal)}function Iki(e){return Hki.parse(e)}async function Lki(e,t){t?.throwIfAborted();for(let n=0;;n++){t?.throwIfAborted();try{return await e()}catch(e){if(t?.throwIfAborted(),n===2||!(e instance

Фрагмент проверенного Desktop-бандла

webview/assets/app-initial-41d268a90bf8.js · смещение 10432015 символов · 30.09.2026. Это выдержка из минифицированного кода, не самостоятельный скрипт.

Копировать

Выдержка JavaScript клиента. Это не Rust и не готовый самостоятельный скрипт.

// ChatGPT-ветка добавляет file и необязательные metadata в FormData.
// Комментарии добавлены для учебника; minified-выдержка может быть неполной.
async function HPc(e,t){let{Request:n}=await Y(async()=>{let{Request:e}=await import(`./chatgpt-request-26b6ea5d126d.js`);return{Request:e}},__vite__mapDeps([802,410,1,411]),import.meta.url),r=t.contentType??(e.type&&e.type.trim().length>0?e.type:`audio/webm`),i=r.split(/[/;]/)[1]??`webm`,a=(t.filename??`codex.${i}`).replace(/"/g,``),o=new FormData;o.append(`file`,new File([e],a,{type:r}));for(let[e,n]of Object.entries({language:t.language,dictation_session_id:t.dictationSessionId,attempt_id:t.attemptId,duration_ms:t.durationMs?.toString(),conversation_id:t.conversationContext?.conversationId,parent_message_id:t.conversationContext?.parentMessageId}))n&&o.append(e,n);t.signal.throwIfAborted();let s=performance.now();t.onRequestStart({audioSentTs:performance.timeOrigin+s});let c=await Lki(()=>n.safePost(`/transcribe`,{requestBody:o,signal:t.signal,retry:!1}).then(Iki),t.signal),l=performance.now();return t.onRequestSuccess({transcriptReceivedTs:performance.timeOrigin+l,transcriptLatencyMs:l-s,transcriptLength:c.text.length}),c}function UPc(e){return new Promise(t=>{let n=URL.createObjectURL(e),r=new Audio(n),i=()=>{URL.revokeObjectURL(n),r.removeEventListener(`loadedmetadata`,a),r.removeEventListener(`error`,o)},a=()=>{let e=r.duration;i(),t(Number.isFinite(e)&&e>=0?e*1e3:void 0)},o=()=>{i(),t(void 0)};r.addEventListener(`loadedmetadata`,a,{once:!0}),r.addEventListener(`error`,o,{once:!0}),r.load()})}var WPc,O7,GPc;function KPc(){return(KPc=e((()=>{WPc=Q(),BL(),q(),O7=nf(),rGn(),_re(),ak(),ds(),$N(),nc(),Vti(),iu(),sa(),X(),fNc(),NNc(),INc(),Pki(),sf(),KNc(),Uki(),iNc(),ud(),qm(),Ju(),NPc(),em(),GPc=250})))()}function qPc(){return Le(ZT,`composer.startDictation`)}function 

Пример вызова

Копировать

Команды Bash. Запускайте из корня комплекта; комментарии объясняют подготовку и действие.

# Выполняйте из корня распакованного комплекта.
source ./scripts/audio-textbook/env.sh
python3 "$repo/scripts/voice-probes/chatgpt-dictation-file.py"   "$INPUT_AUDIO" --auth-file "$auth_file" --dry-run
# Уже проверенная файловая транскрипция (это живой запрос):
# bash "$repo/scripts/voice-probes/chatgpt-transcribe.sh" "$INPUT_AUDIO" --auth-file "$auth_file"

Контракт /transcribe · Потоковая STT в независимом демо · Bash-клиент: отправка файла

Вернуться к карте вызовов ↑

2. Разговор Desktop: отдельный сеанс

Когда интерфейс предлагает Start voice chat, открывается двусторонний голосовой сеанс. Не путайте его с микрофоном диктовки и с квадратом на снимке. Саму кнопку старта разговора в этом проходе не снимали; наличие соответствующего кода не гарантирует её доступность аккаунту.

В Codex-ветке XGi отправляет thread/realtime/start локальному app-server: thread ID, модальность ответа, голос, транспорт и настройки сеанса. App-server управляет агентным сеансом и согласованием соединения. При WebRTC медиа идут по RTC-трекам, а не как файл через этот RPC. appendSpeech, appendText и WebSocket appendAudio - отдельные операции, не названия кнопок микрофона.

В бандле также есть облачная ветка Your Dot с /tbo/{tbo_id}/voice/calls. Её нельзя выдавать за наш воспроизведённый Codex V3: интерфейс и контекст определяют, какая ветка вообще доступна.

Фрагмент проверенного Desktop-бандла

webview/assets/app-initial-41d268a90bf8.js · смещение 4940389 символов · 30.09.2026. Это выдержка из минифицированного кода, не самостоятельный скрипт.

Копировать

Выдержка JavaScript клиента. Это не Rust и не готовый самостоятельный скрипт.

// Этот обработчик вызывает локальный thread/realtime/start; media-байты здесь не показаны.
// Комментарии добавлены для учебника; minified-выдержка может быть неполной.
async function XGi({codexResponseHandoffPrefix:e=``,codexResponseItemPrefix:t=null,codexResponsesAsItems:n=!1,initialItems:r,manager:i,conversationId:a,outputModality:o,prompt:s=null,transport:c,realtimeEndInstructions:l,realtimeSessionId:u=null,realtimeSessionOverrides:d,realtimeStartInstructions:f,voice:p}){if(c.type===`existingCall`){await i.sendRequest(`thread/realtime/start`,{codexResponseHandoffChannelPrefixes:d?.codexResponseHandoffChannelPrefixes,codexResponseHandoffMode:d?.codexResponseHandoffMode,codexResponseItemPrefix:t,codexResponsesAsItems:n,flushTranscriptTailOnSessionEnd:!0,includeStartupContext:!1,outputModality:o,realtimeEndInstructions:l,realtimeSessionId:u,realtimeStartInstructions:f,threadId:a,transport:c,version:d?.version});return}let m={includeStartupContext:!1,flushTranscriptTailOnSessionEnd:!0,codexResponseHandoffPrefix:e,threadId:a,codexResponsesAsItems:n,codexResponseItemPrefix:t,initialItems:r,outputModality:o,realtimeSessionId:u,voice:p,...l==null?{}:{realtimeEndInstructions:l},...f==null?{}:{realtimeStartInstructions:f},...d,...s==null?{}:{prompt:s},transport:c};await i.sendRequest(`thread/realtime/start`,m)}async function ZGi(e,t){return(await Vu(e,t).sendRequest(`thread/realtime/listVoices`,{})).voices}async function QGi({manager:e,conversationId:t}){await e.sendRequest(`thread/realtime/stop`,{threadId:t})}async function $Gi({manager:e,conversationId:t,role:n,text:r}){await e.sendRequest(`thread/realtime/appendText`,{threadId:t,role:n,text:r})}async function eKi({manager:e,conversationId:t,text:n}){await e.sendRequest(`thread/realtime/appendSpeech`,{threadId:t,text:n})}function tKi(){return(tKi=e((()=>{fp(),xli()})))()}var nKi;function rKi

Роль app-server · Наш самостоятельный WebRTC V3 · Запросы и события app-server

Вернуться к карте вызовов ↑

# Выполняйте из корня распакованного комплекта.
source ./scripts/audio-textbook/env.sh
"$voice_python" "$repo/scripts/webrtc-voice-isolated/voice-console.py"   --auth-file "$auth_file" --voice cove --dry-run
# Живой разговор: уберите --dry-run, затем в консоли введите /voice.

// Языковой виджет передаёт pronunciation_language, source=translation и свой текст.
// Комментарии добавлены для учебника; minified-выдержка может быть неполной.
==g?(_={loading:p,play:m,stop:g},t[15]=p,t[16]=m,t[17]=g,t[18]=_):_=t[18];let v=`translation:${r??`auto`}:${n}`,y;t[19]!==n||t[20]!==r?(y=e=>je({pronunciation_language:r,source:`translation`,text:n},{signal:e}),t[19]=n,t[20]=r,t[21]=y):y=t[21];let b;t[22]!==f||t[23]!==_||t[24]!==v||t[25]!==y?(b=(0,$.jsx)(Ne,{errorMessage:f,iconClassName:`icon-sm`,labels:_,playbackId:v,synthesiz

// HTTP pronunciation отправляет JSON и получает Blob; выбранный формат запроса - MP3.
// Комментарии добавлены для учебника; minified-выдержка может быть неполной.
async function ixt(e,{signal:t}={}){return(await gd.getInstance().fetch(`/pronunciation/synthesize?format=mp3`,{method:`POST`,body:JSON.stringify(e),headers:{...pg(),"Content-Type":`application/json`},signal:t})).blob()}var u6,d6,f6,axt;function p6(){return(p6=e((()=>{Y_e(),X(),ge(),_f(),ym(),If(),Is(),u6=new Weak

# Выполняйте из корня распакованного комплекта.
source ./scripts/audio-textbook/env.sh
python3 "$repo/scripts/tts-demos/http-tts.py" chatgpt-text   "$audio_out/pronunciation.mp3" --text-file "$repo/scripts/tts-demos/sample-ru.txt"   --auth-file "$auth_file" --dry-run

// Read Aloud выбирает существующий audio asset либо /synthesize по IDs сообщения.
// Комментарии добавлены для учебника; minified-выдержка может быть неполной.
function lxt(e,{conversationId:t,messageId:n}){let r=e.get(yS,t);if(r==null)return;let i=gae(e.get(eE,t)?.[n]?.message);if(i==null&&n.startsWith(`request-placeholder-`))return;let a=i==null?t6.CHATGPT_VOICE_READ_ALOUD_AUDIO_SOURCE_SYNTHESIZED:t6.CHATGPT_VOICE_READ_ALOUD_AUDIO_SOURCE_AUDIO_ASSET;Fg(e,Gbt,{audioSource:a});let o=e.get(Gm).formatMessage({id:`chatgptConversations.readAloud.error`,defaultMessage:`Unable to read this response aloud`,description:`Error toast shown when Codex cannot synthesize or play a completed ChatGPT assistant response after the user selects Read aloud`}),s=`conversation:${r}:${n}`,c={playbackId:crypto.randomUUID(),conversationId:r,messageId:n,audioSource:a},l=()=>{Fg(e,Kbt,c)};if(i!=null){s6(e,{conversationId:r,playbackId:s,onPlaybackRequested:l,onError:(t,n)=>{n===`play`&&sxt(e,t)||e.get(hp).danger(o,{errorAnalytics:{toastId:`useVoiceReadAloudAudio_onStreamingError`}})},synthesizeAudio:async e=>{let{downloadUrl:t,requestHeaders:n}=i.startsWith(`https://cdn.openai.com/`)||i.startsWith(`/backend-api/`)||i.startsWith(`https://chatgpt.com/backend-api/`)?WOe({status:`success`,download_url:i}):await fge(i.replace(/^file-service:\/\//,``).replace(/^sediment:\/\//,``),{conversationId:r,downloadIntent:!1,showInline:!1,signal:e});return n==null?t:gd.getInstance().fetch(t,{headers:n,signal:e}).then(e=>e.blob())}});return}let u=uxt(e),d=e.get(Sn),f=e.get(it);s6(e,{conversationId:r,cacheKey:u.then(e=>JSON.stringify([d,f,r,n,e])),errorMessage:o,playbackId:s,onPlaybackRequested:l,onPlaybackFailed:(t,n)=>oxt(e,c,t,n),synthesizeAudio:async e=>{let t={conversation_id:r,message_id:n,voice:await u,format:Zbt()},i=new URLSearchParams;for(let[e,n]of Object.entries(t))n!=null&&i.set(e,n);return gd.getInstance().fetch(`/synthesize?${i.toString()}`,{headers:pg(),signal:e})}})}async function uxt(e){let t=e.query.snapshot(Za),n=t.getData()??await t.fetch().catch((

// Выбирается последний законченный ответ ассистента, не любая запись mapping.
// Комментарии добавлены для учебника; minified-выдержка может быть неполной.
function dxt(e,t){let n=e.get(eE,t);if(n==null||e.get(VC,t))return;let r=Bf({current_node:e.get(Gg,t),mapping:n}),i=r.findLast(e=>e.author.role===`assistant`&&(e.channel==null||e.channel===`final`)&&Zhe(e)!=null);i?.id==null||e.get(qD,t)===`streaming`&&r.findLastIndex(e=>e.author.role===`user`)>r.indexOf(i)||lxt(e,{conversationId:t,messageId:i.id})}var fxt;function m6(){return(m6=e((()=>{n6(),X(),OOe(),ge(),ym(),of(),tf(),a6(),If(),ec(),Is(),p6()

// Клиент выбирает воспроизводимый MIME/формат; порядок AAC, MP3, Opus не доказывает текущую ветку.
// Комментарии добавлены для учебника; minified-выдержка может быть неполной.
function Zbt(){let e=Xbt();if(e==null)return;let t=new Audio;for(let[n,r]of[[`audio/aac`,`aac`],[`audio/mpeg`,`mp3`],[`audio/ogg`,`opus`]])if(t.canPlayType(n)&&e.isTypeSupported(n))return r}function Qbt(){return(Qbt=e((()=>{})))()}async function $bt({response:e,mediaSource:t,audioElement:n,form

# Выполняйте из корня распакованного комплекта.
source ./scripts/audio-textbook/env.sh
python3 "$repo/scripts/remote-tts-isolated/chatgpt-read-aloud.py"   "$audio_out/message.mp3" --auth-file "$auth_file" --format mp3 --dry-run
# Для живого запуска задайте свои --conversation-id и --message-id.
# Либо используйте выбор собственного разговора, описанный в README демо.

onClick → codexLinuxReadAloudClick(item, copyText, conversationId, button)
post({action: "speak", source: "button", text})
→ codexLinuxReadAloudSpeak → Kokoro / Piper / system / custom command

# Выполняйте из корня распакованного комплекта.
source ./scripts/audio-textbook/env.sh
# Это выполнение backend без Desktop, не GUI-тест; при запуске возможен звук.
env -u NODE_OPTIONS node "$repo/scripts/tts-demos/button-backend.cjs"   "$repo/scripts/tts-demos/sample-ru.txt"

# Выполняйте из корня распакованного комплекта.
source ./scripts/audio-textbook/env.sh
# Диагностика без чтения текста вслух.
python3 "$repo/scripts/tts-demos/mcp-client.py" doctor   --binary "$repo/target/debug/codex-read-aloud-linux"
# По явному запросу пользователя: замените doctor на read и добавьте --text-file.
# Прямая CLI-озвучка (может включить звук):
# "$repo/target/debug/codex-read-aloud-linux" speak < "$repo/scripts/tts-demos/sample-ru.txt"

# Выполняйте из корня распакованного комплекта.
source ./scripts/audio-textbook/env.sh
"$voice_python" "$repo/scripts/remote-tts-isolated/realtime-tts.py"   "$repo/scripts/remote-tts-isolated/sample-ru.txt" "$audio_out/realtime.wav"   --auth-file "$auth_file" --voice cedar --dry-run

# Выполняйте из корня распакованного комплекта.
source ./scripts/audio-textbook/env.sh
python3 "$repo/scripts/remote-tts-isolated/appserver-tts.py"   "$repo/scripts/remote-tts-isolated/sample-ru.txt" "$audio_out/appserver.wav"   --codex "$(command -v codex)" --auth-file "$auth_file" --voice cedar --dry-run

# Выполняйте из корня распакованного комплекта.
source ./scripts/audio-textbook/env.sh
# Перекодирование - не локальная STT; распознаёт удалённый сервис.
ffmpeg -nostdin -v error -n -i "$INPUT_AUDIO"   -ar 24000 -ac 1 -c:a pcm_s16le "$audio_out/stt-input.wav"
"$voice_python" "$repo/scripts/realtime-stt-isolated/realtime-transcribe.py"   "$audio_out/stt-input.wav" --auth-file "$auth_file" --dry-run

# Выполняйте из корня распакованного комплекта.
source ./scripts/audio-textbook/env.sh
"$voice_python" "$repo/scripts/webrtc-voice-proxy/proxy-voice.py" --dry-run --auth-file "$auth_file"
# Живой разговор и отчёт маршрутов: команды находятся в README ниже.

Архитектура

Зачем вообще нужен app-server

Чтобы читать следующие схемы, сначала разделим роли. Интерфейс принимает действие пользователя. App-server предоставляет клиенту операции ядра Codex: вход, чаты, ходы, разрешения и события. Ядро ведёт агентную работу. В выбранном CLI V3 медиапроцесс обслуживает звук, а app-server создаёт разговор и держит канал событий. Поэтому часть обязанностей можно перенести в самостоятельное демо, не перенося весь Codex.

// Одна из разновидностей команды внутри процесса.
// Остальные варианты enum и импорты остаются в полном исходнике.
enum ClientCommand {
    Request {
        request: Box<ClientRequest>,
        response_tx: oneshot::Sender<IoResult<RequestResult>>,
    },
}

Так разные интерфейсы используют одно ядро, не дублируя агентную логику. На схеме показаны роли, а не обязательное число процессов: интерфейс и app-server могут связываться внутри одного процесса.

Для аудио роль зависит от пути. В файловой диктовке Desktop получает token через app-server, но Electron сам отправляет multipart-файл. В CLI /voice app-server создаёт call, возвращает SDP и слушает sideband, а звук отправляет helper напрямую по WebRTC. В WebSocket appendAudio сэмплы, наоборот, действительно проходят через RPC. Нельзя объединить эти три случая словом "прокси".

Подмена model base URL или HTTP-прокси не делает его RTP-реле. Для голоса отдельно нужны маршруты HTTPS call, WSS sideband и ICE/media. RTP может идти по выбранным ICE-кандидатам напрямую или через разрешённый TURN, если такой сервер настроен. Наше демо не настраивает TURN; среда с закрытым UDP может не пройти media даже после успешного HTTPS.

thread/realtime: что именно принимает RPC

Контракт: app-server-protocol/src/protocol/v2/realtime.rs. Здесь описаны клиентские типы. Какие сочетания transport/version поддерживает сервер, проверяется отдельно; наличие поля в схеме ещё не доказывает живой вызов.

Роли схемы

main → console | file_probe
asyncio.run(...)

микрофон → захват → сэмплы
полученный аудиопоток → декодирование → динамики

audio/opus; RTP clock=48000; channels=2 в SDP
synthetic silence: mono; 960 samples / 20 ms; live capture здесь не доказан
create_data_channel("oai-events")

thread/realtime/start { transport: { type: "webrtc", sdp }, version: "v3" }
HTTP headers: OpenAI-Alpha: quicksilver=v2
session.model: gpt-live-1-codex

/voice → helper offer → RPC start
SDP notification → helper apply answer
transcript notifications → TUI

клиент → запрос → удалённый сервис
клиент ← ответ/события ← удалённый сервис

UI → app-server → core Session → ModelClient
voice: Session → create call → sideband / handoff

model → request tool → core policy → execution
voice demo: delegation.created → error + close

Что именно передаётся по сети

Сначала определяем байты, затем выбираем способ отправки. Имя файла, MIME и звук внутри него - три разных вещи.

Контейнер и кодек

Контейнер хранит данные и описание дорожек. Кодек задаёт представление звука. WAV - контейнер, он не всегда содержит PCM; в наших WAV лежат несжатые PCM16-отсчёты. FLAC и MP3 нельзя превратить в WAV переименованием. HTTP-диктовка отправляет контейнер целиком, WSS-демо извлекает PCM, WebRTC кодирует отсчёты в Opus.

PCM16LE и размер

PCM - последовательность чисел, описывающих звук. Signed PCM16 занимает два байта на отсчёт; LE означает, что младший байт идёт первым. Mono 24 кГц даёт 24000 × 1 × 2 = 48000 байт в секунду. У V3-демо 48 кГц: 20 мс дают 960 отсчётов, то есть 1920 байт до Opus.

Поясняющий фрагмент или результат, не готовая команда. Его смысл указан в этом разделе.

01 00 FF FF
# Два учебных signed PCM16LE отсчёта: +1 и -1.
# Это не WAV и не осмысленная запись речи.

Base64 и JSON

Base64 записывает бинарные байты текстом для JSON. Он не сжимает и не шифрует звук. Для предыдущих четырёх байтов получится AQD//w==. Формат декодированных байтов определяется контрактом, а не самим Base64.

Учебный JSON. Поля и ограничения объяснены рядом; значения ID не являются личными.

{"type":"input_audio_buffer.append","audio":"AQD//w=="}

Это корректная форма учебного сообщения, но два отсчёта недостаточны для транскрипции. WAV-заголовок RIFF в поле audio нашего WSS-клиента не попадает.

Частота записи и RTP clock

Sample rate задаёт число PCM-отсчётов в секунду. RTP clock задаёт шкалу временных меток пакетов; для Opus здесь это 48 кГц. Из RTP clock нельзя вывести частоту микрофона или число его каналов. SDP описывает соединение, а ICE выбирает рабочую пару адресов; сами они аудиозаписью не являются.

Почему V3, v2 и GA не противоречат друг другу

GA означает General Availability - общедоступное семейство API, а не версию нашего WebRTC-сеанса. CLI voice V3, выбранный WS v2 в appendSpeech, заголовок OpenAI-Alpha: quicksilver=v2 и V1-каталог голосов принадлежат разным уровням. Их номера не взаимозаменяемы; голос выбирается из каталога конкретного endpoint и версии.

Какие ID нельзя менять местами

Codex thread/turn относятся к чату и ходу агента. ChatGPT conversation/message нужны для сохранённого ответа. Call ID соединяет signaling, media и sideband звонка. STT item_id связывает committed-вход с транскрипцией, GA response_id связывает дельты с конкретным ответом. Похожий вид строки не делает эти ID взаимозаменяемыми.

Точные контракты и словарь доступны из каждой практической главы.

Подготовка переносимого комплекта

Книга и исходники переезжают вместе. Вход, устройства и зависимости принадлежат новой машине и в архив не входят.

Распакуйте архив и откройте index.html. Команды выполняйте из корня audio-textbook. env.sh вычисляет корень по собственному расположению и помещает результаты в .runtime/output. Venv после переноса создаётся заново: его внутренние пути не являются переносимой частью.

Команды Bash. Запускайте из корня комплекта; комментарии объясняют подготовку и действие.

# Выполняйте в корне распакованного audio-textbook.
source ./scripts/audio-textbook/env.sh
# Эта проверка не читает credential и не обращается к сервису.
python3 ./tooling/verify.py

Для живой пробы укажите AUDIO_AUTH_FILE перед source или задайте auth_file в этом терминале. Во всех командах выбранный файл передаётся явно. Если вход хранится только в keyring, файл не появится автоматически. Истёкший вход обновляется штатным клиентом отдельно; демо не делает refresh основного профиля.

Зависимости, venv и сборка локального helper. Начинайте с dry-run. Сетевой доступ к приватному ChatGPT endpoint зависит от сервиса и аккаунта; исторический успех не является обещанием доступа на другой машине.

Аудиоспособ · аудиофайл принят

Готовый файл → текст: ChatGPT /transcribe

Начнём с самого прямого способа: у нас уже есть запись, и нужен текст. Клиент отправляет целый файл через multipart POST. Контейнер остаётся в запросе, а распознавание происходит на удалённой стороне. Здесь не нужны SDP, WebRTC и управление ходами агента.

Для этой задачи не нужны ни разговор, ни thread/realtime/start. В Desktop файл собирается из записи микрофона. Наш скрипт пропускает захват и берёт уже существующий файл. В обоих случаях распознавание выполняется удалённо; app-server помогает Desktop получить вход, но не является STT-движком.

Что проходит по сети

Boundary разделяет части multipart, а не аудиочанки. Для FLAC частота/каналы описаны внутри файла; клиент не объявляет raw PCM rate. Одна запись может содержать много кодированных FLAC-фреймов, но это по-прежнему один file в запросе.

Как запустить

Каталог: открыть локальную папку. Инструкция и требования.

# Выполняйте из корня распакованного комплекта.
source ./scripts/audio-textbook/env.sh
bash "$repo/scripts/voice-probes/chatgpt-transcribe.sh" --auth-file "$auth_file"    "$INPUT_AUDIO"

Как проверять и где возможна ошибка

Сравниваем извлечённую multipart file с исходным файлом побайтово. MIME выбирается по расширению. Для известных контейнеров перед сетью сверяется сигнатура: MP3 или WAV с именем .flac получают локальный отказ. Это не полное декодирование: повреждённые фреймы внутри правильной сигнатуры ещё может обнаружить сервис. Конкретный серверный HTTP-код для mismatch не проверяли.

Блоки схемы и code-map

recorder.ondataavailable → chunks
new Blob(chunks) → FormData.set("file", blob)

renderer request → getAuthToken → applicationNetwork.fetch
eligible 401 → auth_refresh → one retry

audio_bytes = audio_file.read_bytes()
multipart file = audio_bytes

POST /backend-api/transcribe
Content-Disposition: form-data; name="file"; filename="raven.flac"
Content-Type: audio/flac
<исходные FLAC-байты>

Учебный клиент

Один файл. Без форка и app-server.

Когда вместо готового файла сервису нужны отсчёты звука, меняется упаковка. Наш клиент читает WAV локально и отправляет его PCM-содержимое в Base64 JSON по WSS. RIFF-заголовок остаётся на машине. Эта файловая STT-проба не является уменьшенной копией CLI /voice: у них разные контракты и результаты.

Ссылки рассчитаны на открытие этого HTML как локального файла. Если браузер запрещает переход в каталог, скопируйте путь и откройте его в файловом менеджере. На другой машине задайте свой вход и пересоздайте venv.

Это сопоставление двух способов распознавания, не обещание одинакового wire-формата. В /voice идёт Opus по WebRTC и возвращается также аудиоответ. Следующее WSS-демо использует raw PCM и возвращает только финальный текст.

Почему это работает без app-server

Наш клиент сам выполняет минимум его сетевых обязанностей: читает credential, открывает защищённое соединение и задаёт session. Для выделенного STT не нужны thread, SDP, голосовой helper, handoff и ответы голосом. Это другой режим API с той же идеей удалённого распознавания, а не воспроизведение внутренних запросов TUI.

Какие события посылает скрипт

Поясняющий фрагмент или результат, не готовая команда. Его смысл указан в этом разделе.

← session.created
→ session.update: type=transcription, PCM16 24 кГц,
                  transcription.model=gpt-transcribe, turn_detection=null
← session.updated
→ input_audio_buffer.append: {audio: "Base64 PCM…"}  # несколько чанков
→ input_audio_buffer.commit                           # завершить вход
← input_audio_buffer.committed: item_id
← conversation.item.input_audio_transcription.completed:
    item_id, transcript
→ stdout: только финальный текст

Чанк - до 48 000 PCM-байтов (1 секунда записи). Чанки уходят подряд, без ожидания секунды между отправками. Для файла длиной 7,21 с получилось 8 чанков и 346 070 аудиобайтов. Base64 увеличивает размер примерно на треть; JSON и TLS добавляют служебные данные. Демо проверяет финальный item_id, даже если события пришли в другом порядке.

Протокол: официальный Realtime transcription. ChatGPT OAuth в этом API - проверенный здесь эксперимент, не обещанная замена Platform key для всех аккаунтов.

pcm = audio.readframes(frames)
len(pcm) == frames * 2

for offset in range(0, len(pcm), 48000):
    chunk = pcm[offset:offset + 48000]

{"type":"input_audio_buffer.append","audio":"<base64 raw PCM>"}
{"type":"input_audio_buffer.commit"}

if committed in completed:
    return completed[committed].strip()

клиент → запрос → удалённый сервис
клиент ← ответ/события ← удалённый сервис

Практика

Запуск шаг за шагом

Контракт уже разобран; теперь воспроизведём его. Сначала подготовим WAV нужного формата и выполним dry-run без входа и сети. Затем явно выберем собственный auth-файл. Успешная транскрипция должна принадлежать item_id именно нашего отправленного буфера, а не соседнему событию в сокете.

1. Изолировать клиент и зависимости

Выполняйте блоки в одном терминале: переменная demo_dir сохраняется в этом shell. Нужны Python 3 с venv, ffmpeg и доступ к сети.

# Выполняйте из корня распакованного комплекта.
source ./scripts/audio-textbook/env.sh
# Создаём новый каталог, не трогая репозиторий или настройки Codex.
demo_dir=$(mktemp -d "$audio_out/realtime-stt-demo-XXXXXX")
# Переносим единственный клиент: он не импортирует код форка.
cp "$repo/scripts/realtime-stt-isolated/realtime-transcribe.py" "$demo_dir/"
# Python-пакеты будут только в этом каталоге.
python3 -m venv "$demo_dir/venv"
# Сетевой клиент, НЕ локальная модель распознавания.
"$demo_dir/venv/bin/pip" install websocket-client==1.9.2

2. Подготовить файл и проверить без сети

Конвертация не распознаёт речь. Она приводит FLAC к формату API. -n запрещает перезапись; -t 60 берёт не более 60 секунд.

# Выполняйте из корня распакованного комплекта.
source ./scripts/audio-textbook/env.sh
# Вместо raven.flac можно указать свою разрешённую к передаче запись.
ffmpeg -v error -n -i "$INPUT_AUDIO" -t 60    -ac 1 -ar 24000 -c:a pcm_s16le "$demo_dir/input.wav"
# Только проверка WAV и расчёт передачи: нет сети и чтения токена.
"$demo_dir/venv/bin/python" "$demo_dir/realtime-transcribe.py" --auth-file "$auth_file"    "$demo_dir/input.wav" --dry-run

Ожидается JSON с network: false, credentials_read: false, размером PCM и количеством чанков. Пример требует mono PCM16, 24 кГц, 0,2-60 с. Более длинные записи надо отдельно разбивать; автоматического разбиения здесь нет.

3. Сделать удалённую транскрипцию

# Выполняйте из корня распакованного комплекта.
source ./scripts/audio-textbook/env.sh
# Теперь запись действительно отправится на api.openai.com через WSS.
# Секрет читается из tokens.access_token в указанном auth.json.
"$demo_dir/venv/bin/python" "$demo_dir/realtime-transcribe.py"    "$demo_dir/input.wav"    --auth-file "$auth_file"    --model gpt-transcribe --timeout 90

В stdout - только итоговый текст. Ошибка - в stderr и ненулевой exit code. Токен не вставляется в исходник, argv или отчёт; файл входа не изменяется. Скрипт не умеет обновлять истёкший токен. Для proxy-профиля с маркером 0000 этот вариант не подходит.

Варианты запуска

# Выполняйте из корня распакованного комплекта.
source ./scripts/audio-textbook/env.sh
# Потоковая STT-модель; данный скрипт всё равно печатает только финал.
"$demo_dir/venv/bin/python" "$demo_dir/realtime-transcribe.py"    "$demo_dir/input.wav" --model gpt-live-transcribe --auth-file "$auth_file"
# Официальная API-key альтернатива, если у вас есть собственный Platform key.
# Укажите существующий приватный файл с ключом, не значение ключа.
"$demo_dir/venv/bin/python" "$demo_dir/realtime-transcribe.py"    "$demo_dir/input.wav" --api-key-file "${AUDIO_API_KEY_FILE:?Укажите свой файл ключа}"

Эти два варианта приведены по протоколу и интерфейсу клиента; живой запрос в этом исследовании проверен только для gpt-transcribe + текущий ChatGPT OAuth. Не приписываем эту проверку всем моделям и способам входа.

Сохранить текст и не принять сбой за успех

# Выполняйте из корня распакованного комплекта.
source ./scripts/audio-textbook/env.sh
# Новые файлы доступны только вам. Перенаправление создаёт файл даже при сбое.
umask 077
if "$demo_dir/venv/bin/python" "$demo_dir/realtime-transcribe.py"    "$demo_dir/input.wav" --timeout 90 > "$demo_dir/transcript.txt" --auth-file "$auth_file"; then
  printf 'Текст сохранён: %s\n' "$demo_dir/transcript.txt"
else
  printf 'Транскрипция не получена; не используйте пустой файл как результат.\n' >&2
fi

А можно curl?

Этот конкретный режим - полноценный двусторонний WebSocket: handshake, JSON-события, аудиочанки, commit и ожидание результата. Обычный curl -F file=… не воспроизводит его. Для готового аудиофайла есть отдельный HTTP transcription API; наш ранее проверенный ChatGPT-файловый пример тоже работает иначе.

Не смешивайте HTTP-диктовку Desktop, CLI WebRTC v3 и учебный WSS STT. У них разная упаковка данных и разный жизненный цикл.

Аудиоспособ · локальные движки проверены

Локальная озвучка и оболочки кнопки, CLI, MCP

Теперь решим обратную задачу на этой машине. Текст передаётся выбранному движку, движок создаёт звук, проигрыватель выводит его в динамики. Кнопка, CLI и MCP лишь вызывают этот путь. Скачивание модели и локальный синтез - разные этапы; после подготовки локальный движок не обязан обращаться к сервису.

Piper, Kokoro и eSpeak уже дали аудиофайлы. Speech Dispatcher проверен как системное воспроизведение. Кнопка, команда speak и MCP-инструмент read_aloud только передают текст движку. Через custom command можно подключить HTTP TTS, но тогда удалённым становится выбранный backend, а не MCP-протокол.

Что проходит по сети

Частоту выбирает модель/движок. Kokoro samples приводятся к signed PCM16 LE, Piper заполняет WAV через библиотеку. ONNX-файлы - веса модели, не аудио. started=true у MCP означает запуск процесса, а не успешное декодирование всей речи.

Как запустить

Каталог: открыть локальную папку. Инструкция и требования.

# Выполняйте из корня распакованного комплекта.
source ./scripts/audio-textbook/env.sh
local_tts_out="$(mktemp -d "$audio_out/local-tts.XXXXXX")"
python3 "$repo/scripts/tts-demos/local-file.py" \
  espeak "$repo/scripts/tts-demos/sample-ru.txt" \
  "$local_tts_out/espeak.wav" --language ru
ffmpeg -nostdin -v error -i "$local_tts_out/espeak.wav" -f null -
# Piper/Kokoro используют уже установленные модели в cache; команды ниже.
"$TTS_DEMO_CACHE/venv/bin/python" "$repo/scripts/tts-demos/local-file.py" \
  piper "$repo/scripts/tts-demos/sample-ru.txt" \
  "$local_tts_out/piper.wav" --model "$TTS_DEMO_CACHE/models/ru_RU-denis-medium.onnx"
"$TTS_DEMO_CACHE/venv/bin/python" "$repo/scripts/tts-demos/local-file.py" \
  kokoro "$repo/scripts/tts-demos/sample-en.txt" \
  "$local_tts_out/kokoro.wav" --model "$TTS_DEMO_CACHE/models/kokoro-v1.0.onnx" \
  --voices "$TTS_DEMO_CACHE/models/voices-v1.0.bin" --voice bm_george --language en-us
python3 "$repo/scripts/tts-demos/mcp-client.py" doctor

На этой машине espeak-ng не установлен в PATH: команда выше использует извлечённый бинарник в cache. Если он установлен системно, задайте --espeak-bin espeak-ng. Piper/Kokoro используют существующее изолированное окружение; на другой машине сначала нужен setup-local.sh с загрузкой моделей, около398МиБ.

Кнопка, speak и MCP: отдельные точки входа

Следующие команды могут воспроизвести звук. Это не запуск Desktop: первая проверяет JS-backend кнопки в Node, вторая вызывает Rust CLI, третья - тот же helper по STDIO MCP. Для Speech Dispatcher модели ONNX не нужны. Они проверены отдельными backend/STDIO тестами; started=true означает запуск, а не завершённую речь.

# Выполняйте из корня распакованного комплекта.
source ./scripts/audio-textbook/env.sh
local_demo="$repo/scripts/tts-demos"
# Системная озвучка через Speech Dispatcher.
bash "$local_demo/spd-stdin.sh" < "$local_demo/sample-ru.txt"
# CLI speak, текст приходит в stdin.
CODEX_LINUX_READ_ALOUD_COMMAND="$local_demo/spd-stdin.sh" \
  "$repo/target/debug/codex-read-aloud-linux" speak \
  < "$local_demo/sample-ru.txt"
# MCP read_aloud: сервер создаёт только эта команда.
CODEX_LINUX_READ_ALOUD_COMMAND="$local_demo/spd-stdin.sh" \
  python3 "$local_demo/mcp-client.py" read --text-file "$local_demo/sample-ru.txt"
# Тест JS-backend кнопки без UI приложения.
env -u NODE_OPTIONS CODEX_LINUX_READ_ALOUD_COMMAND="$local_demo/spd-stdin.sh" \
  node "$local_demo/button-backend.cjs" "$local_demo/sample-ru.txt"

Если Rust helper не собран, вместо пути target/debug задайте существующий бинарник через --binary у MCP-клиента. Инструкция сборки есть в общем TTS-документе. Не надо включать patch кнопки или менять установленный payload ради этого теста.

Как проверять и где возможна ошибка

Сверяются непустой сигнал, WAV header и полное декодирование. MCP tests используют контролируемую команду, проверяют stdin, busy, stop и socketpair. Команды для настоящего backend не требуют UI, но воспроизведение может дать звук в помещении. Здесь Desktop не запускается.

Блоки схемы и code-map

button → JS backend → engine
CLI speak → Rust helper → engine
MCP read_aloud → Rust helper → engine

PiperVoice.load(model).synthesize_wav(text, audio)
Kokoro(model, voices).create(text, voice=...)
espeak-ng --stdout -v ru --stdin

text → selected local engine → PCM → player
custom command может отдельно вызвать HTTP TTS

Аудиоспособ · MP3 получен

Текст → MP3: /pronunciation/synthesize

Для удалённой озвучки собственной строки в исследованном Desktop найден pronunciation endpoint. В него передаётся текст, язык и source, а обратно приходит MP3. У нашего примера нет параметра выбора голоса; возможности соседних TTS API на этот контракт переносить нельзя.

Что проходит по сети

Частота и каналы принадлежат полученному MP3, а не входной строке. Нельзя объявить mp3-файл WAV сменой расширения. Если вместо MP3 приходит JSON/HTML или пустой ответ, демо отказывает; audio/mpeg само по себе ещё не доказывает декодируемость.

Как запустить

Каталог: открыть локальную папку. Инструкция и требования.

# Выполняйте из корня распакованного комплекта.
source ./scripts/audio-textbook/env.sh
tts_http_out="$(mktemp -d "$audio_out/tts-http.XXXXXX")"
python3 "$repo/scripts/tts-demos/http-tts.py" --auth-file "$auth_file"    chatgpt-text "$tts_http_out/voice.mp3"    --text-file "$repo/scripts/tts-demos/sample-ru.txt"
ffmpeg -nostdin -v error -i "$tts_http_out/voice.mp3" -f null -

Как проверять и где возможна ошибка

Тест перехватывает JSON до сети и сверяет endpoint, метод и поля. Отдельные тесты не дают сохранить пустой ответ, JSON/HTML с audio MIME, redirect или перезаписать существующий файл. ffmpeg проверяет весь поток. Ошибка HTTP и ошибка декодера - разные результаты.

Блоки схемы и code-map

// Это форма вызова endpoint; авторизация и обработка ответа показаны в полном демо.
// Комментарии добавлены для учебника; minified-выдержка может быть неполной.
fetch("/pronunciation/synthesize?format=mp3", {
  method: "POST", body: JSON.stringify(payload)
}).then(response => response.blob())

text = text_file.read_text(encoding="utf-8").strip()
{"text": text, "pronunciation_language": "ru", "source": "translation"}

url, method, body = build_request(args, text)
download_audio(url, method, body, headers, output, timeout)

Аудиоспособ · оба формата получены

Существующий ответ → MP3 или AAC: /synthesize

Озвучка сохранённого ответа устроена иначе: клиент передаёт ID разговора и сообщения, а не сам текст. Сервис находит ответ и возвращает аудио. Нужны ChatGPT conversation/message IDs; Codex thread ID относится к другой сущности. Начните с явных собственных IDs, автоматический выбор закреплённого чата оставьте как дополнительный режим.

Этот способ полезен, когда ответ уже существует в ChatGPT. Сначала надо найти правильный assistant message активной ветки. Ошибка 404 для другого ID не означает, что весь endpoint не работает. Для произвольной строки используйте pronunciation или Realtime, а не подменяйте ID своим текстом.

Что проходит по сети

Для MP3/AAC частота, каналы и длительность определяются декодером ответа. Base64 здесь не используется. MIME и сигнатура помогают отвергнуть JSON/HTML, но окончательно поток проверяет ffmpeg. AAC-байты нельзя подавать как raw PCM.

Как запустить

Каталог: открыть локальную папку. Инструкция и требования.

# Выполняйте из корня распакованного комплекта.
source ./scripts/audio-textbook/env.sh
read_out="$(mktemp -d "$audio_out/chatgpt-read.XXXXXX")"
python3 "$repo/scripts/remote-tts-isolated/chatgpt-read-aloud.py" --list-voices --auth-file "$auth_file"
# Без явных IDs нужен закреплённый ChatGPT-чат текущего account ID.
python3 "$repo/scripts/remote-tts-isolated/chatgpt-read-aloud.py" --auth-file "$auth_file"    "$read_out/answer.mp3" --voice Juniper --format mp3 --conversation-id "${CHATGPT_CONVERSATION_ID:?Укажите свой conversation ID}" --message-id "${CHATGPT_MESSAGE_ID:?Укажите свой message ID}"
# Для AAC задайте новый путь answer.aac и --format aac.
ffmpeg -nostdin -v error -i "$read_out/answer.mp3" -f null -

Как проверять и где возможна ошибка

Проверяются account boundary, активная ветка, кодирование query, выбор backend voice ID, отказ redirect и новая запись 0600. Личные message ID и ответ не опубликованы. Демо может требовать --conversation-id и --message-id, если закреплённого собственного чата нет.

Блоки схемы и code-map

current_node → parent → видимый assistant message
GET /synthesize?conversation_id=…&message_id=…

GET /synthesize?conversation_id=…&message_id=…&voice=juniper&format=mp3

GET /settings/voices?spoken_language=ru&voice_mode=advanced
GET /synthesize?...&voice=<backend_id>&format=aac

Аудиоспособ · WAV получен

Текст → аудиочанки: GA Realtime WebSocket

GA Realtime позволяет передать текст и собрать звуковой ответ из событий. Клиент принимает Base64 PCM-чанки своего response_id, ждёт completed и только после этого создаёт WAV. Это генеративный ответ: он не обещает дословно повторить каждую букву. GA WSS и WebRTC V3 - разные способы связи.

Realtime полезен, если дальше нужен потоковый разговор, но для простого чтения он остаётся моделью, которая может изменить текст. В штатном CLI 0.156.1 /voice выбран WebRTC V3; показанный здесь GA WSS - другой воспроизведённый способ. На схемах он сопоставлен со штатным голосовым трактом, но не назван его копией.

Что проходит по сети

Чанки delta - транспортные порции raw PCM, их длина не равна обязательно одной секунде или фразе. Клиент склеивает байты и проверяет выравнивание PCM16. WAV header записывается только локально после completed. У CLI RTP-clock 48 кГц, у этого raw PCM contract 24 кГц - это разные величины.

Как запустить

Каталог: открыть локальную папку. Инструкция и требования.

# Выполняйте из корня распакованного комплекта.
source ./scripts/audio-textbook/env.sh
rt_tts_out="$(mktemp -d "$audio_out/realtime-tts.XXXXXX")"
"$voice_python"    "$repo/scripts/remote-tts-isolated/realtime-tts.py" --auth-file "$auth_file"    "$repo/scripts/remote-tts-isolated/sample-ru.txt"    "$rt_tts_out/answer.wav" --voice cedar
ffmpeg -nostdin -v error -i "$rt_tts_out/answer.wav" -f null -

Как проверять и где возможна ошибка

Тесты проверяют порядок created/update/create, чужой response_id, ошибочный Base64, нечётный PCM, пустой и незавершённый ответ. Пустой done или только звук без правильного завершения - не успех. Параметры output format проверяются в отправленном session.update.

Блоки схемы и code-map

{"type":"conversation.item.create","item":{"type":"message","role":"user","content":[{"type":"input_text","text":"…"}]}}
{"type":"response.create"}

session.update: audio.output.format={type:'audio/pcm',rate:24000}
base64(delta) → raw PCM16 mono → WAV
created.id == delta.response_id == done.response.id

Аудиоспособ · эксперимент воспроизведён

Текст → голос через app-server appendSpeech

Теперь вызовем озвучку через локальный интерфейс app-server. Наш опыт передаёт текст в appendSpeech и получает аудиодельты уведомлениями. Он запускает отдельный временный профиль и использует WS v2. OAuth, переданный в поле apiKey этого локального опыта, не становится ключом OpenAI Platform.

Прежняя проба с обычным ChatGPT auth не прошла локальную проверку API-key режима. Временный app-server получил тот же собственный OAuth через apiKey login; вход Desktop не переключался. Этот способ остаётся экспериментом.

Что проходит по сети

В проверенных ответах sampleRate=24000 и numChannels=1. Это PCM16, без контейнера в data. Ширина сэмпла подтверждена живым декодированием, а в схеме RPC не задаётся отдельным sampleWidth. Нельзя считать любой Base64 из уведомления WAV-файлом.

Как запустить

Каталог: открыть локальную папку. Инструкция и требования.

# Выполняйте из корня распакованного комплекта.
source ./scripts/audio-textbook/env.sh
app_tts_out="$(mktemp -d "$audio_out/appserver-tts.XXXXXX")"
python3 "$repo/scripts/remote-tts-isolated/appserver-tts.py" --auth-file "$auth_file"    "$repo/scripts/remote-tts-isolated/sample-ru.txt"    "$app_tts_out/answer.wav" --codex "$(command -v codex)"    --version v2 --voice ash
ffmpeg -nostdin -v error -i "$app_tts_out/answer.wav" -f null -

Как проверять и где возможна ошибка

Тесты запускают только fake STDIO сервер: подтверждают выбор голоса, первую delta до RPC-ack, очистку профиля при success/error/timeout и отсутствие чужого env. Для живого результата использован настоящий отдельный app-server. SIGKILL/отключение питания не дают Python выполнить finally: временный профиль может остаться.

Блоки схемы и code-map

thread/realtime/appendSpeech {threadId:"…", text:"…"}

initialize → account/login/start {type:"apiKey",apiKey:<тот же OAuth>}
thread/start ephemeral → realtime/start websocket/v2
appendSpeech → outputAudio/delta

Реальная система

Что запускает команда codex

Теперь вернёмся к разговору. В CLI 0.156.1 TUI, app-server и codex-voice-host выполняют разные роли, но не обязательно живут в трёх отдельных процессах. Встроенный app-server связывается с TUI через InProcess; возможны daemon по Unix-сокету и remote-режим. STDIO относится к нашим демо, которые действительно запускают отдельный процесс.

1. 1. Интерфейс TUIВы вводите /voice или нажимаете F8. CLI запускает helper и получает предложение соединения - SDP.
2. 2. Локальный app-serverПолучает thread/realtime/start, использует вход Codex и создаёт удалённый разговорный сеанс WebRTC v3.
3. 3. Звук и текстHelper передаёт аудио по WebRTC. App-server получает текстовые события через отдельный sideband и возвращает их TUI.

Что именно делает app-server

• Связывает голосовой сеанс с thread и его контекстом; обрабатывает start/stop и состояние.
• Берёт авторизацию через штатную систему Codex. Создаёт удалённый call, возвращает SDP answer и call ID.
• Открывает sideband - отдельный WebSocket для текстовых и служебных событий. Переводит их в уведомления для клиента.
• Поддерживает передачу задач обычному агенту (handoff). Голосовой режим - не только STT, он может отвечать и делегировать работу.

App-server не является локальным Whisper. Его можно использовать без Electron-клиента, но он не заменяет WebRTC/helper и не превращает thread/realtime/start в endpoint загрузки FLAC.

Как включить в самом CLI

В терминале запустите codex. Внутри существующего основного чата: /voice - начать/остановить, /voice mute - выключить/включить микрофон, /voice settings - параметры. Стандартные клавиши: F8 и Ctrl + X; пользовательская раскладка может их менять. Voice не запускается в side conversation.

Основание: TUI / realtime, TUI → app-server, клавиши.

Обмен данными

Не один запрос, а несколько каналов

Разговор создаётся в несколько шагов. Локальный start задаёт WebRTC и version=v3. HTTPS-запрос передаёт SDP offer и получает answer; затем открываются WebRTC-медиа и WSS sideband. RPC result подтверждает вызов, уведомления приносят SDP и реплики, медиапоток приносит звук. Эти события нельзя объединять в один ответ start.

Ответ на RPC thread/realtime/start - пустой объект. SDP answer доставляется отдельно через ThreadRealtimeSdpNotification; принятие старта - через started-уведомление. Клиент должен обрабатывать события, а не ждать аудио или SDP в одном синхронном ответе.

Адреса: что подтверждено кодом

Для ChatGPT provider путь создания call - realtime/calls относительно настроенной backend base URL. Пример дефолтного маршрута из исходников:

Форма HTTP-запроса или ответа. Учебные значения не заменяют вход и целый аудиофайл.

POST https://chatgpt.com/backend-api/codex/realtime/calls?intent=quicksilver&architecture=avas
JSON: { "sdp": "…", "session": { … } }

WSS sideband V3 по умолчанию:
wss://api.openai.com/v1/live/<call_id>

Это маршруты по коду версии 0.156.1, не захваченный URL нашего живого CLI. Provider/base URL и experimental overrides могут их изменить. Публичный API-режим использует иной маршрут создания V3 call (/v1/live) и multipart, поэтому нельзя механически подменить только домен.

А что с thread/realtime/appendAudio?

В app-server существуют и другие realtime-операции, в том числе передача аудиочанков в WebSocket-пути. Но исследуемый CLI выбрал WebRTC: его микрофонный поток не идёт через appendAudio. API надо читать вместе с выбранными transport и version. appendSpeech также не означает "загрузить файл и распознать": это отдельная операция голосового вывода.

appendAudio принимает threadId и объект audio: data, sampleRate, numChannels, необязательные samplesPerChannel и itemId. Это аудиочанк, не путь к файлу на диске. appendText передаёт текст и роль, appendSpeech - текст для произнесения, stop закрывает сеанс, listVoices возвращает список голосов. Эти операции не нужны нашему выделенному STT-клиенту.

Поля и уведомления: app-server protocol / v2 / realtime.rs. Поддержку конкретной операции нужно проверять для выбранной версии и транспорта; наличие типа в схеме не является проверкой живого вызова.

Почему обычного proxy base URL недостаточно

Основание: создание call, sideband и маршруты, V3 transcript-события, Opus/RTP.

Аудиоспособ · живой V3 разговор подтверждён

Самостоятельная консоль /voice по WebRTC V3

Самостоятельный клиент переносит только необходимые обязанности: создаёт call, держит WSS и обслуживает WebRTC через aiortc. Он не запускает Codex и не выполняет инструменты. Если сервис просит делегацию агентной работы, клиент закрывает сеанс. Файловая проба проверяет одну реплику и получение звука; фиксированный хвост не доказывает полный media drain.

В CLI интерфейс передаёт SDP через app-server, а helper отправляет звук. В нашем варианте один процесс делает обе эти работы: aiortc держит медиа, aiohttp создаёт call и sideband. Так мы убрали зависимость от Codex, но сохранили V3 signaling. Агентную часть намеренно не переносили: запрос delegation.created завершает разговор, никакая команда модели не выполняется.

Что проходит по сети

Микрофон начинает работать после /voice и соединения. /voice mute прекращает capture и очищает backlog; clock и синтетическая тишина остаются. /voice settings показывает устройства/голос, /quit и Ctrl+C закрывают всё. Для файла нужен WAV48к monoPCM16, 0,2-60с. Файловая проба не открывает микрофон/динамики. AEC не реализован: при живом разговоре нужны наушники.

Как запустить

Каталог: открыть локальную папку. Инструкция и требования.

# Выполняйте из корня распакованного комплекта.
source ./scripts/audio-textbook/env.sh
voice_demo="$repo/scripts/webrtc-voice-isolated"
voice_venv="$voice_venv"
python3 -m venv "$voice_venv"
"$voice_venv/bin/pip" install -r "$voice_demo/requirements.txt"
"$voice_venv/bin/python" "$voice_demo/voice-console.py" --dry-run --auth-file "$auth_file"
"$voice_venv/bin/python" "$voice_demo/voice-console.py" --list-devices --auth-file "$auth_file"
"$voice_venv/bin/python" "$voice_demo/voice-console.py" --auth-file "$auth_file"
# Теперь введите /voice. Для файловой пробы - команда в README.

Как проверять и где возможна ошибка

Локальный peer-to-peer тест реально проходит ICE/DTLS/SRTP/Opus и декодирует тон. Это проверка медиакода, не удалённого доступа. Отдельная живая проба проверила call, sideband, оба RTP-направления и финальный ответ. В первом запросе отсутствовал alpha header: 400 invalid_quicksilver_alpha_header, challenge=False. Заголовок найден в realtime_request_headers и исправлен; также сверён default model ядра. Cookies/attestation не подделывались. Аппаратный разговор с каждым устройством не проверен.

Блоки схемы и code-map

if muted: return bytes(1920)
frame.sample_rate=48000; frame.pts += 960
mute: stop capture + clear queue + epoch++

POST {sdp,session:{model:"gpt-live-1-codex",audio:{output:{voice:"cove"}},...}}
apply SDP answer
WSS /v1/live/<call_id>  // без session.update

клиент → запрос → удалённый сервис
клиент ← ответ/события ← удалённый сервис

pc.addTransceiver(track, direction="sendrecv")
setCodecPreferences([audio/opus])
pc.createDataChannel("oai-events")

AudioResampler(format="s16", layout="mono", rate=48000)
speaker.write(pcm) | save_wav(output, pcm)

Переносимый комплект: подготовка и запуск. Ссылки и код рядом с этим файлом; команды выполняются из корня после подключения scripts/audio-textbook/env.sh. Вход и модели не входят в архив.

Результат

Голос работает через proxy.
Но не весь поток.

После прямого разговора можно отдельно исследовать маршрут. В датированной proxy-пробе HTTPS и WSS прошли через CONNECT, а WebRTC UDP шёл отдельно. Далее разберём, какой журнал подтверждает каждый из этих выводов и чего из него узнать нельзя.

Это отдельный вариант прямого WebRTC-демо. Он не запускает Codex, app-server или Desktop, не меняет профиль входа и не выполняет агентную работу. В него перенесены только обязанности, нужные для разговора: свой вход, создание call, согласование WebRTC, captions и закрытие ресурсов.

Прикладной HTTP proxy и системный сетевой маршрут - разные вещи. Прямой UDP из нашего процесса всё ещё может проходить через NAT или VPN машины. Их мы здесь не исследовали. Также клиентский журнал не показывает, какой OAuth-аккаунт proxy выбрал на своей стороне.

Контракт и наблюдение

Два endpoint и отдельный медиапоток

Endpoint обозначает операцию сервиса, выбранный ICE peer обозначает медиасоединение конкретного звонка. Поэтому HTTP proxy может обслуживать создание call и WSS, не перенося звук. Порт и IP в прошлой пробе - наблюдение, а не постоянный адрес загрузки WAV.

В этом разговоре нет запроса "загрузить WAV на /transcribe". Файл нужен только нашему источнику PCM. Сервис получает описание соединения по HTTPS, управляющие события по WSS и Opus-пакеты по WebRTC.

Как записать адрес аудиопотока

В последней проверенной пробе 30.09.2026 выбранный медиапоток шёл к 135.220.40.201:3478 по UDP. Для наглядности этот адрес можно записать как udp://135.220.40.201:3478. Это условная запись адреса и порта, а не HTTP/HTTPS endpoint и не команда запуска.

Адрес выбирается при согласовании WebRTC через SDP/ICE и может меняться между звонками; в коде демо он не закреплён. Отправить туда WAV или FLAC через curl нельзя: сначала нужен установленный WebRTC-сеанс, который согласует параметры и передаёт Opus в зашифрованных DTLS-SRTP медиапакетах. HTTPS-вызов создания call и WSS sideband имеют свои URL из таблицы выше; UDP-медиа идёт отдельно, в обход нашего HTTP CONNECT proxy.

Подтверждение: событие selected_ice в журнале финальной пробы - remote_host=135.220.40.201, remote_port=3478, transport=udp. Сопоставление со счётчиками RTP и полученным WAV описано в отчёте проверки. Роль медиасоединения и функции наблюдения разобраны в карте кода.

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

V3 JSON, alpha-заголовок и поля событий взяты из CLI 0.156.1. Но aiortc генерирует собственный SDP, ICE credentials и DTLS-параметры. Его Opus encoder преобразует наш mono PCM в stereo, тогда как helper CLI кодирует mono; у обоих SDP объявляет opus/48000/2. RTP clock 48 кГц не доказывает stereo входного файла. Идентификаторы и бинарные пакеты этих клиентов различаются.

Наши originator и User-Agent честно называют изолированный клиент. Cookies и integrity/attestation не копируются. Демонстрация не обещает неразличимость клиентов и не обходит запреты доступа.

Почему нельзя просто взять 0000

В сохранённом RubyMITM 1.1.113 marker bridge относится к responses и alpha/search. Voice требует обычного собственного ChatGPT Bearer. Proxy может заменить его активным gateway Bearer; этот механизм находится на сервере, не в демо. Подстановка аккаунта в конкретном production-сеансе требует серверного свидетельства - client 201/101 сам по себе не показывает email.

Исходная архитектура

Что делает app-server в штатном CLI

Штатная схема объясняет владение соединениями: app-server создаёт call и держит sideband, helper обслуживает media. Наличие HTTPS_PROXY не доказывает, что UDP тоже пошёл в CONNECT. Native CLI через proxy в этой работе не принят живой пробой; схема основана на исходниках.

В штатной системе TUI управляет разговором, app-server связывает его с ядром Codex, а helper владеет звуковым устройством и WebRTC. Авторизация, signaling, captions, thread/turn и возможная агентная делегация проходят через app-server. Пакеты WebRTC helper отправляет самостоятельно.

Настройка HTTPS_PROXY для app-server не означает, что helper начнёт отправлять UDP в HTTP proxy. App-server нужен не для пересылки каждого аудиопакета, а для связи разговора с управлением агентом. В простом демо этой агентной части нет, поэтому создавать локальный app-server незачем.

Изолированный клиент

Что перенесено в наш процесс

Наш proxy-клиент держит эти обязанности в одном Python-процессе и использует loopback relay для управляющих TLS-соединений. Relay считает байты, но не расшифровывает TLS и не переносит UDP. Gateway MITM, если он настроен с доверенной CA, является отдельной границей доверия.

Aiohttp направляет управляющие соединения в relay. Одновременно aiortc согласует media-соединение с сервисом. Свой сохранённый вход читается только перед живым запросом.

WAV сначала проверяется: PCM16, mono, 48 кГц, 0,2-60 секунд, полный набор сэмплов. При ошибке сеть ещё не открыта. После готовности WebRTC InputTrack отправляет PCM кадрами по 20 мс; aiortc кодирует их в Opus. Ответ декодируется обратно в PCM и сохраняется как новый WAV.

WSS не является запасным транспортом аудио. Он получает captions существующего V3 call. При delegation.created клиент останавливает сеанс: у него нет ядра агента, прав выполнения команд и контекста проекта.

Воспроизведение

Запустить и прочитать маршрут

Проверяйте запуск по фазам: CONNECT 200, создание call 201, WSS 101, выбранная ICE-пара, оба RTP-направления и декодированный ответ. Первые три статуса не доказывают звук. Текущий wrapper не читает bootstrap при dry-run, list-devices и help.

Все файлы демо находятся в отдельном каталоге webrtc-voice-proxy. Его можно перенести целиком. Подробная установка зависимостей и варианты bootstrap находятся в README.

Проверка контракта без сети

# Выполняйте из корня распакованного комплекта.
source ./scripts/audio-textbook/env.sh
"$voice_venv/bin/python"    "$repo/scripts/webrtc-voice-proxy/proxy-voice.py" --dry-run --auth-file "$auth_file"

Этот вызов не открывает auth.json, CA, proxy env или микрофон. Python и wrapper при dry-run не читают bootstrap. Он нужен только для живого proxy-запуска.

Реальная проба с файлом

# Выполняйте из корня распакованного комплекта.
source ./scripts/audio-textbook/env.sh
proxy_demo="$repo/scripts/webrtc-voice-proxy"
proxy_run="$(mktemp -d "$audio_out/proxy-voice.XXXXXX")"
ffmpeg -nostdin -v error -n -i "$INPUT_AUDIO"    -ar 48000 -ac 1 -c:a pcm_s16le "$proxy_run/input.wav"
bash "$proxy_demo/run-proxy.sh"    --file "$proxy_run/input.wav" --output "$proxy_run/answer.wav"    --report "$proxy_run/routes.json" --voice cove    --auth-file "$auth_file" --timeout 30 --max-seconds 45
ffmpeg -nostdin -v error -i "$proxy_run/answer.wav" -f null -
ffprobe -v error -show_entries stream=codec_name,sample_rate,channels,bits_per_sample    -show_entries format=duration,size -of json "$proxy_run/answer.wav"

ffmpeg только меняет аудиоформат. Распознавание и разговор происходят удалённо. Успех требует RTP в обе стороны, ненулевого декодированного сигнала и финального текста обеих сторон. Одно стартовое приветствие сервиса не считается ответом на файл.

Разговор без Codex

# Выполняйте из корня распакованного комплекта.
source ./scripts/audio-textbook/env.sh
proxy_run="$(mktemp -d "$audio_out/proxy-voice-console.XXXXXX")"
bash "$repo/scripts/webrtc-voice-proxy/run-proxy.sh"    --report "$proxy_run/routes.json" --voice cove --auth-file "$auth_file"

В консоли: /voice - начать/остановить; /voice mute - убрать/вернуть микрофон; /voice settings - устройства и голос; /quit - выход. Захват начинается только после создания разговора. Для реального микрофона нужны наушники, PortAudio и корректно выбранное устройство; аппаратная проба в этой итерации не выполнялась.

Журнал - не просто список настроек

client_response даёт статус endpoint. proxy_tcp_connected показывает настоящий TCP peer relay; proxy_connect_response - целевой host:443 и ответ proxy. selected_ice показывает выбранную медиапару, udp_sendto - адреса попыток UDP sendto, rtp_stats - отправленные и принятые пакеты. Эти независимые наблюдения вместе дают основание разделить маршруты.

По умолчанию оба управляющих соединения идут через proxy; NO_PROXY игнорируется. Опция --sideband-route direct существует только для явного сравнения. Автоматического fallback нет. Её маршрутизация проверена на локальном стенде, не на реальном call другого gateway-аккаунта.

Каждый блок схемы

Роль, вход, выход и исходник

Здесь каждое наблюдение привязано к месту в коде. Попытка sendto ещё не означает доставку UDP. Выбранная ICE-пара, положительные RTP-счётчики, captions и ненулевой декодированный звук вместе дают более сильное подтверждение. Полный внешний маршрут машины этими данными не устанавливается.

Приёмка

Что доказано, а что осталось за границей

Успешный файл подтверждает конкретный клиент и конкретную пробу. Он не подтверждает физический микрофон, текущий аккаунт gateway, native CLI через proxy или все остальные STT/TTS endpoints. Для этих выводов нужны собственные наблюдения.

Файловый разговор через proxy воспроизведён именно как WebRTC V3, без замены на GA WebSocket. Локальный тест воспроизводит весь цикл на своих TLS/RTC peers. Негативные тесты проверяют отсутствие скрытого direct fallback, проверку CA, отказ 407, закрытие и безопасный журнал.

# Выполняйте из корня распакованного комплекта.
source ./scripts/audio-textbook/env.sh
"$voice_venv/bin/python" -W error::ResourceWarning    -m unittest discover    -s "$repo/scripts/webrtc-voice-proxy"    -p 'test_*.py' -v
bash -n "$repo/scripts/webrtc-voice-proxy/run-proxy.sh" --auth-file "$auth_file"

Отдельно не проверялись: физический разговор с микрофоном/динамиками, нативный CLI /voice через proxy, текущий upstream email gateway, его полная серверная трасса и аппаратный AEC. Другие STT/TTS endpoint из основного учебника нельзя считать прошедшими proxy только потому, что прошёл этот V3-сеанс.

У HTML проверяются структура, локальные ссылки, каждая SVG-ссылка и логика hash/focus/history на DOM-модели. Схемы можно отдельно отрендерить через librsvg/ffmpeg. Это не браузерная проверка desktop/mobile/print: просмотр локального HTML заблокирован URL-политикой, обход не применялся.

Полные результаты и границы: отчёт проверки. Знания о старой настройке: Codex Proxy Setup. Документация транспорта: aiohttp proxy support, CPython audit events.

Совместимость

Где наши запросы совпадают со штатными, а где нет

Совместимость означает, что стороны понимают переданные данные. Она не означает одинаковый клиент. HTTP boundary, SDP, ICE, TLS-стек и идентификаторы закономерно отличаются. Мы исправляем упаковку и описание формата, но не копируем cookies, integrity или attestation и не обещаем неразличимость обращения.

У демо нет Electron networking, штатного refresh и состояния основного клиента. Поэтому сравнение ниже отдельно показывает совпадающие поля и различия среды исполнения.

Старый 403 challenge у файла и дальнейший 200 с другим набором HTTP headers показывают различие клиентского контекста. Они не доказывают, что причиной была одна конкретная строка User-Agent или что теперь любой запрос будет принят. В новой V3-пробе 400 был явной ошибкой версии: invalid_quicksilver_alpha_header. Исправление протокольного заголовка не является обходом защиты.

Часть параметров закрытого сервиса неизвестна: внутренние модели ChatGPT HTTP, полные ограничения, учёт расхода и логика допуска. Их не заменяем догадками. Публичная документация Realtime описывает GA API, но не доказывает приватный V3 контракт Codex. Здесь V3 привязан к тегу исходников и конкретной живой пробе.

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, в этом исследовании не проверялось.

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

Почему SDP answer ещё не означает подключённый звук

HTTP-сигнализация передаёт описание будущего соединения. Сам звук пойдёт по адресу и порту, которые выберет ICE. После этого должны установиться DTLS и защищённый RTP. Поэтому отдельный успешный POST /core/offer не доказывает ни доставку микрофона, ни распознавание.

Клиент отправляет offer, Core отвечает answer. Эти описания содержат кодеки, кандидаты и параметры защиты, но не записанное аудио. ICE проверяет пары адресов. Только найденная рабочая пара позволяет перейти к DTLS и передаче защищённых Opus-пакетов. Если ICE-запросы не получают ответа, Sonora и замена ASR-модели до этого этапа не доберутся.

Сигнализация: JSON с SDP, без аудиофайла

{"type":"offer","sdp":"v=0\r\n...","session_id":"00000000-0000-4000-8000-000000000001"}

POST /core/offer, Content-Type: application/json. Ответ содержит type: "answer", sdp и нормализованный session_id. Многоточие выше обозначает сокращённый учебный SDP: это не запускаемый offer. Исходники: negotiate.ts, handle_offer.py.

STUN, TURN и ICE - разные роли

STUN Binding сообщает клиенту адрес, который виден снаружи. Кандидат srflx содержит этот адрес. TURN выделяет ретранслятор и даёт кандидат relay, если прямой маршрут недоступен. ICE проверяет пары локальных и удалённых кандидатов и выбирает путь. STUN не ретранслирует Opus и не гарантирует, что другой peer доступен через его NAT.

stun:stun.gis-master.ru:3478 - UDP-сервис, не HTTP endpoint. В ICE между peer тоже используются STUN-проверки, но это не запрос к сервису 3478. Их нельзя смешивать в одной метрике. У Core в проверенном коде iceServers = []; в просмотренном answer были только внутренние host-кандидаты.

DTLS: защита медиа после найденного маршрута

DTLS согласует ключи SRTP по выбранному ICE-пути. Это не WebSocket и не TLS-соединение POST /core/offer. Проверяем состояние транспорта; new при нерабочем ICE не доказывает ошибку сертификата. В live-пробе до установленного DTLS дело не дошло.

Opus: подтверждать выбранный кодек, а не только наличие в SDP

# Учебный фрагмент SDP; 111 - пример динамического payload type.
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
# RTP-clock 48 kHz не означает, что файл для ASR должен быть 48 kHz stereo.
# Выбранный кодек проверяется через codecId активного RTP-потока в getStats().

Opus переносится в RTP/SRTP-пакетах, не в MP3 и не в RIFF/WAV. Core декодирует его и отдельно ресемплирует в 16 kHz mono PCM для ASR bridge. Проверка должна связать outbound-rtp / inbound-rtp → codecId → codec и выбранную ICE-пару. Поддержка FEC/DTX в предложении не означает фактический эффект на потери. Подробный список проверок находится в главе Sonora / Opus.

Первичные контракты: STUN RFC 8489, Opus RTP RFC 7587, WebRTC Stats. Далее разбираем конкретную ошибку 701.

WebSocket не задаёт формат: что идёт внутри каждого WSS

WebSocket - двусторонний транспорт. В одном соединении можно передавать команды разговора, в другом - PCM в Base64, в третьем - протокол NATS. Само слово WSS не отвечает на вопрос, передаётся ли там звук. Это определяется контрактом конкретного клиента.

Одинаковый внешний JSON не делает протоколы совместимыми

{"type":"input_audio_buffer.append","audio":"AAAAAA=="}

Это форма события Realtime STT. Четыре декодированных байта в примере - два нулевых PCM16-сэмпла, а не запись фразы. В запросе должны быть реальные сэмплы нужной частоты, порядок событий и commit. Передать такой JSON прямо в NATS /ws нельзя: NATS требует собственное соединение, подписку и publish с subject.

# Иллюстрация NATS framing, не curl-запрос к WebSocket.
SUB nats.events.user123 1\r\n
MSG nats.events.user123 1 <число байт UTF-8 payload>\r\n
{"kind":"message","role":"assistant","text":"Пример"}\r\n
# Настоящий клиент рассчитывает длину и ведёт INFO/CONNECT/PING/PONG.
# Поля JSON события зависят от producer; этот текст не задаёт новую схему.

HTTP CONNECT-прокси способен провести HTTPS/WSS TCP-туннель, если endpoint и авторизация разрешены. WebRTC UDP-медиа от этого не становится проксированным. Поэтому в proxy-главах HTTP/WSS и ICE/RTP проверяются отдельно. У нашего контура есть ещё межсервисный NATS-канал; его статус также не подтверждает медиа.

NATS: где переносится PCM, а где только события и команды

В webrtc-komaroff NATS соединяет несколько стадий. Core публикует декодированные кадры для ASR bridge, bridge возвращает текст, Core передаёт запрос агенту, а frontend получает события через NATS over WebSocket. Это разные subjects и разные payload. Один зелёный индикатор NATS не проверяет весь путь.

Core → ASR bridge: бинарный пакет, не файл

Subject начинается с inference.whisper.stream., ответ - с inference.whisper.text.. Суффикс строится из stream/session routing; точную композицию смотрите в handle_track. Формат пакета: [meta_len:u32 big-endian][meta_json:UTF-8][PCM:int16 little-endian]. Для 20 мс при 16 kHz mono это 320 сэмплов, или 640 байт PCM, плюс заголовок и metadata.

{"type":"frame","seq":1,"sample_rate":16000,"sample_width":2,"channels":1,"session_id":"00000000-0000-4000-8000-000000000001"}

# Локальная сборка одного нулевого кадра. Не подключает NATS и не отправляет звук.
import json
meta = {"type": "frame", "seq": 1, "sample_rate": 16000,
        "sample_width": 2, "channels": 1}
header = json.dumps(meta, ensure_ascii=False).encode("utf-8")
pcm = bytes(320 * 2)  # 20 мс тишины, int16 LE mono.
packet = len(header).to_bytes(4, "big") + header + pcm
assert len(packet) == 4 + len(header) + 640  # Метаданные считаем в байтах, не символах.

Пакет type: "end" завершает поток и не содержит PCM. У такого payload нет RIFF-заголовка. Если поставить WAV вместо raw PCM, парсер может принять контейнерные байты за отсчёты. Если указать неверную частоту, звук получится ускоренным или замедленным, без обязательной ошибки сервиса. Исправлять надо producer, metadata и consumer вместе, а не только MIME.

Первичные исходники сохранены локально: producer, парсер, bridge. Состав и SHA256 среза находятся в source-manifest.json.

Bridge → ASR: уже WAV-фраза

Silero возвращает интервалы речи. Bridge вырезает соответствующие исходные сэмплы и записывает WAV PCM16 mono 16 kHz. Затем HTTP-клиент отправляет файл в настроенный LINTO_HTTP_URL с языком; адрес зависит от среды, это не неизменный публичный endpoint. Точный multipart contract и ответ text/plain разобраны в таблице форматов.

Silero не очищает запись. Browser AEC/NS или Sonora работают раньше, на клиенте. В bridge могут быть короткие буферы и ограничения фразы, которые влияют на контрольный короткий вопрос. Проверять "2+2" надо по четырём артефактам: доставленному PCM, интервалу VAD, фактически отправленному WAV и тексту ASR. По одной ошибочной строке невозможно выбрать, какой этап виноват.

Agent → frontend: события, отдельные от медиа

В проверенной frontend-конфигурации используется nats.events.user123; стек задаёт префиксы nats.events. и nats.agent.. Агентный request/reply и UI publish относятся к другому контракту, чем PCM. Для нескольких окон нужно фильтровать события по активной сессии и проверить разграничение доступа, а не просто добавить UUID в JSON.

Для непрерывного аудио нужен ограниченный бюджет очередей, число worker и контроль возраста кадра. Текущий semaphore ограничивает одновременно выполняемый publish, но не число накопленных task. Локальная проба с mock publish показала 100 созданных задач и только 3 вошедших вызова. Это подтверждение механизма, не измерение production-утечки. Реализация и критерии находятся в главе очередей.

Правило диагностики: NATS connected → подписка → кадры → end/flush → phrase → ASR result → agent result. На каждом переходе нужны свои session_id, seq, длительность и статус; секреты, полный SDP и личную речь в общий лог не сохраняем.

STUN 701: сервис отвечает, но отдельное семейство адресов даёт ошибку

2 октября 2026 года браузер писал "STUN host lookup received error" для stun.gis-master.ru:3478. Проверки не подтвердили исчезновение сервиса: DNS A разрешался, UDP Binding возвращал корректный ответ, и Chrome собирал IPv4 srflx-кандидаты. В этой пробе событие 701 относилось к локальному IPv6-интерфейсу.

Что действительно наблюдали

701 создаёт браузер, когда не смог получить ответ STUN/TURN по проверяемому пути. Код находится вне диапазона STUN error response. Текст про lookup уточняет причину конкретной попытки. Не всякий 701 означает отсутствие AAAA; такой вывод получен только из сочетания DNS и address-family в нашей пробе. Определение W3C и libwebrtc ResolveStunAddress / OnResolveResult объясняют эту границу.

Почему 701 не была основной причиной отказа в этой пробе

Временная browser-only проба использовала проверенный IPv4-адрес STUN и синтетическую тишину. Ошибка 701 исчезла, но ICE к Core всё равно не подключился. У наблюдаемых пар было 20-21 отправленное check и 0 ответов; номинированной пары не было, DTLS оставался new. Значит, убрать это событие недостаточно для восстановления звука.

{"probe":"IPv4 STUN literal, synthetic silence","ice_candidate_errors":[],"ipv4_srflx":2,"ice_checks_sent_range":[20,21],"ice_check_responses":0,"nominated_pair":false,"dtls_state":"new","transport_bytes_sent":0,"transport_bytes_received":0}

Core отдавал внутренние host-кандидаты 10.200.0.140, 10.0.14.22, 172.18.0.48 с динамическими UDP-портами. В исходном DRS опубликован 19303/UDP, но это не заставляет aiortc привязать именно этот порт. Точный NAT/firewall hop, фактически применённый port mapping и выбранный runtime image ещё не установлены. Частный кандидат сам по себе не доказывает невозможность всех NAT-сценариев; отсутствие ответов доказывает отказ проверенных пар.

Куда и когда "делся" сервис

Исчезновение не подтверждено. В Git видно только историю конфигурации: 14.10.2025 hostname был у frontend; 21.10.2025 legacy aiortc-путь вернули на GIS STUN; 10.12.2025 новый Core handler появился с пустым iceServers. Последняя дата - изменение исходников, не доказанная дата deployment или удаления STUN.

В этой проверке не удалось получить инфраструктурное описание STUN: Insight был недоступен в разрешённом браузерном пути, SSH не принял существующий ключ. Поэтому процесс, контейнер, software/vendor и владелец сервиса неизвестны. Называть его coturn без этих данных нельзя. Датированный журнал выводов: очищенный evidence.

Как повторить проверку без микрофона

# Из корня распакованного комплекта. Отправляется только STUN Binding, не аудио.
python3 scripts/network-lab/stun_probe.py stun.gis-master.ru --family 4
# Проверка IPv6 отдельно: DNS-ошибка здесь не отменяет успешный IPv4-путь.
python3 scripts/network-lab/stun_probe.py stun.gis-master.ru --family 6
# Сначала проверяем разрешение DNS в своей сети; старый IPv4 не фиксируем в production.
python3 -m unittest discover -s scripts/network-lab -p 'test_*.py' -v

Исходник STUN-пробы использует только Python standard library. Новый запуск обращается к названному серверу и печатает адрес, который увидел STUN; не публикуйте этот вывод без очистки. Все unit-тесты работают без сети. Для основной неисправности идём в диагностику Core.

Live: что теперь проверено, а что осталось неизвестным

Прежний документ описывал исходники и локальные пробы без полной live-приёмки. Теперь к нему добавлены транспортные наблюдения от 2 октября. Они подтверждают конкретный отказ подключения, но не проверенную точность модели и не завершённую поставку всего стека.

Разделяем HTTP, события, медиа и распознавание

Source двух опубликованных UI-коммитов: 2e5aa37 и e29be7f; их snapshots лежат отдельно от старого архитектурного среза. Результат очистки и диагностики ресурсов в локальном loopback также не переносится на production. В этом задании live-сервис повторно не вызывался и приложение не перезапускалось: мы фиксируем уже собранные результаты, а не выдаём их за новый эксперимент.

Следующая проверка соединения

На стороне Core сначала сопоставляем UDP-порты из SDP с фактическими сокетами процесса, публикацией Swarm, firewall и маршрутом обратно к браузерному кандидату. Затем проверяем один допустимый прямой маршрут или локальный TURN внутри нужной сети. Не копируем чужой диапазон портов наугад и не снимаем защиту ради теста. Приёмка - nominated pair, DTLS connected, рост RTP-счётчиков в обе стороны и декодированный контрольный звук.

После доставки повторяем короткую контрольную фразу и речь с известным текстом. Для шума используем одинаковый clean reference, фиксированную смесь и сохранённую конфигурацию. Ошибки VAD, обрезанные слова, пустой WAV и неверную частоту учитываем отдельно от ошибки ASR. План таких испытаний связан с доработкой распознавания и метриками.

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 наружу запрещён. Можно синхронизировать выбранные обезличенные события, когда сеть снова появилась, но модельный контекст и голос не должны уходить туда без отдельной политики.

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

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, ни другая библиотека ещё не показали у нас выигрыш; цели и порядок внедрения приведены в плане работ.

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

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 и сетевой приёмки.

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

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

Начинаем с наблюдаемого отказа сети. Потом фиксируем корректную доставку и очистку речи. Лишь после этого меняем сегментацию, ASR и сценарий агента. Sonora включена в план как нативный клиентский процессор, а не как замена Silero и не как серверное исправление ICE.

Пример Codex полезен границами ответственности: медиа отдельно, управление отдельно, маленькие очереди, явная отмена и локальная обработка звука. В независимый контур переносим эти принципы и доступные локальные библиотеки. ChatGPT endpoint, OAuth и внешние модели автономную поставку не обеспечивают.

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 tooling/probe_audio_bounds.py --source-root "$WEBRTC_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 могут быть следующими решениями, но только если измеренный сценарий этого требует.

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

Проверки

Как отличить правильную упаковку от рабочего результата

Проверка идёт по слоям: сначала локальный формат, затем доступ к сервису, соответствие ответа запросу, завершение результата и полное декодирование аудио. Неверная частота raw PCM может дать принятую, но искажённую речь вместо HTTP-ошибки. Нельзя считать MIME, HTTP 200 или started:true доказательством всего результата.

Первым делом проверяем то, что отправляет клиент. HTTP-перехватчик извлекает file из multipart и сравнивает с исходником; Realtime fake socket проверяет session и собирает обратно PCM из Base64. Затем смотрим на результат: правильный ID, completed/done и полный decode. Только после этого делаем вывод о живом способе.

Прогон тестов

# Выполняйте из корня распакованного комплекта.
source ./scripts/audio-textbook/env.sh
python3 -W error::ResourceWarning -m unittest discover -s "$repo/scripts/tts-demos" -p "test_*.py" -v
python3 -W error::ResourceWarning -m unittest discover -s "$repo/scripts/voice-probes" -p "test_*.py" -v
python3 -W error::ResourceWarning -m unittest discover -s "$repo/scripts/realtime-stt-isolated" -p "test_*.py" -v
python3 -W error::ResourceWarning -m unittest discover -s "$repo/scripts/remote-tts-isolated" -p "test_*.py" -v
"$voice_venv/bin/python" -W error::ResourceWarning -m unittest discover -s "$repo/scripts/webrtc-voice-isolated" -p "test_*.py" -v
python3 -m unittest discover -s "$repo/scripts/audio-textbook" -p "test_*.py" -v

Ни один из этих тестов не стартует Desktop. Fake RPC может запустить только свой тестовый процесс. Живые файлы сохраняются в отдельный каталог; в учебнике только параметры и счётчики, без личных ответов и credentials.

Ограничения и невоспроизведённые способы

Проверка самого учебника

Отчёт приёмки: 87 Python-тестов, Node DOM-mock, 20 SVG и датированные живые пробы.

Статические проверки контролируют уникальность ID, все SVG-ссылки, локальные пути, shell-команды, JS syntax и логику hash/deep-link/history/focus. SVG проверяются отдельно рендерером. Полный просмотр HTML в разрешённом браузерном окружении ранее заблокирован URL-политикой для локальных HTML-файлов; обход через другой браузер, headless или HTTP server не делаем. Поэтому desktop/mobile/print screenshot и настоящая клавиатура браузера остаются непроверенными. Логический DOM-тест не заменяет визуальную приёмку.

Границы знания

Что проверено, а что ещё нет

В конце отделим источник знания от результата. Исходник показывает возможный путь, mock проверяет нашу обработку, локальный peer проверяет WebRTC без сервиса. Историческая живая проба имеет дату и условия. При редактировании 01.10.2026 доступ аккаунта, микрофон и Desktop заново не проверялись.

Получение 96 символов подтверждает непустой ответ сервиса, но не независимую проверку дословной точности. Аудио, транскрипт и credentials не добавлены в репозиторий. Совпадение версии установленного бинарника и тега - не побайтовое доказательство воспроизводимой сборки.

Если не заработало

Code-map: от действия к исходнику

Проверить демо самостоятельно

# Выполняйте из корня распакованного комплекта.
source ./scripts/audio-textbook/env.sh
# Только локальные тесты, без сервиса, credentials и запуска приложения.
python3 -W error::ResourceWarning -m unittest discover \
  -s "$repo/scripts/realtime-stt-isolated" \
  -p 'test_*.py' -v
# Проверить, что за CLI установлен: эти команды не включают микрофон.
command -v codex
codex --version
codex login status
codex features list

Небольшой словарь

Первичные источники и соседние документы

• OpenAI: Realtime transcription - session, append/commit, item_id и финальный transcript.
• Codex rust-v0.156.1 - исследованный тег; commit 81e8e29b2956dfe9b092c63953a9ed282781e77c.
• Ранее собранный разбор voice / app-server - учитывать версию: старые маршруты и результаты не переносить на новый CLI автоматически.
• HTTP-диктовка и удалённый TTS - другие аудиосценарии форка и независимых клиентов.

Контракты: endpoint, данные и ответы

Схемы показывают направление, здесь приведены конкретные сообщения. ID и PCM-отсчёты учебные. Это не дампы личного сеанса. На каждый контракт распространяются условия собственного входа и датированного evidence соответствующей главы.

{
  "id": 10,
  "method": "thread/realtime/start",
  "params": {
    "threadId": "demo-thread",
    "version": "v3",
    "outputModality": "audio",
    "transport": {
      "type": "webrtc",
      "sdp": "<SDP offer>"
    }
  }
}

[
  {
    "id": 10,
    "result": {}
  },
  {
    "method": "thread/realtime/sdp",
    "params": {
      "threadId": "demo-thread",
      "sdp": "<SDP answer>"
    }
  },
  {
    "method": "thread/realtime/transcript/done",
    "params": {
      "threadId": "demo-thread",
      "role": "user",
      "text": "Привет"
    }
  }
]

Согласование SDP и управление helper; это не HTTP-запрос.

Звук с устройства / в устройство и состояние helper.

{
  "sdp": "<SDP offer>",
  "session": {
    "instructions": "Отвечай кратко",
    "audio": {
      "output": {
        "voice": "cove"
      }
    },
    "delegation": {
      "type": "client"
    },
    "model": "gpt-live-1-codex"
  }
}

HTTP 200/201; тело начинается с v=0 (SDP answer), заголовок Location содержит call ID.

{
  "type": "session.close"
}

{
  "type": "turn.done",
  "turn": {
    "role": "assistant",
    "transcript": "Привет"
  }
}

Микрофон → локальные PCM-сэмплы → Opus → WebRTC-пакеты.

WebRTC-пакеты → Opus decoder → PCM → динамики или WAV нашего демо.

Content-Disposition: form-data; name="file"; filename="demo.flac"
Content-Type: audio/flac

<байты FLAC целиком>

{
  "text": "Привет"
}

{
  "type": "session.start",
  "dictation_session_id": "demo-session",
  "attempt_id": "demo-attempt",
  "config": {
    "language": null,
    "input_audio_format": "pcm16",
    "sample_rate_hz": 48000,
    "num_channels": 1,
    "provider_mode": "streaming_sse",
    "transcript_delivery_mode": "final_only"
  }
}

Connect-info: websocketUrl + protocols; поток затем возвращает транскрипт. Полный контракт текстовых событий в этой итерации не воспроизведён.

[
  {
    "type": "session.update",
    "session": {
      "type": "transcription",
      "audio": {
        "input": {
          "format": {
            "type": "audio/pcm",
            "rate": 24000
          },
          "transcription": {
            "model": "gpt-transcribe"
          },
          "turn_detection": null
        }
      }
    }
  },
  {
    "type": "input_audio_buffer.append",
    "audio": "AQD//w=="
  },
  {
    "type": "input_audio_buffer.commit"
  }
]

{
  "type": "conversation.item.input_audio_transcription.completed",
  "item_id": "demo-item",
  "transcript": "Привет"
}

{
  "text": "Привет",
  "pronunciation_language": "ru",
  "source": "translation"
}

HTTP 200; аудиобайты MP3 (audio/*); проверить полное декодирование ffmpeg.

GET /backend-api/synthesize?conversation_id=demo&message_id=answer&voice=juniper&format=mp3 (учебные ID, не рабочий разговор)

Бинарный MP3 или AAC. Демо поддерживает mp3/aac; оригинальный клиент проверяет возможности MediaSource.

[
  {
    "type": "conversation.item.create",
    "item": {
      "type": "message",
      "role": "user",
      "content": [
        {
          "type": "input_text",
          "text": "Привет"
        }
      ]
    }
  },
  {
    "type": "response.create"
  }
]