OpenAI Realtime API + Aplikacje zmieniające głos

Budowanie aplikacji asystenta głosowego z OpenAI Realtime API otwiera nową przestrzeń projektowania: co jeśli głos, który model słyszy, nie jest twoim surowym mikrofonem, ale przetworzonym głosem osoby przechodzącym przez lokalny zmianę głosu? Zmiana powoduje odblokowaniem asystentów zablokowanych osobę, nauczycieli nauki języka z natywnym wejściem akcentu, agentów wsparcia klienta z markowanymi głosami i agentami AI, którzy brzmiają spójnie niezależnie od tego, kto nimi operuje.

Ten przewodnik obejmuje pełny potok — przechwycenie audio, routing wirtualnego mikrofonu, uzgodnienie WebRTC, budżet opóźnienia i praktyczne kompromisy, które napotkasz w produkcji.

Szybki przewodnik

Etap	Zakres opóźnienia	Notatki
Efekt głosu DSP	10-20 ms	Wysokość, equalizacja, reverb — uruchomiony na CPU
Klonowanie głosu AI	50-300 ms	Zależy od modelu i sprzętu
Sieć (klient→API)	15-40 ms	WebRTC UDP, regionalny punkt końcowy
Wnioskowanie Realtime API	300-800 ms	Model + generowanie TTS
Sieć (API→klient)	15-40 ms	Pierwszy token transmisji
Całkowita obustronna	0,5–1,5 s	Akceptowalne dla większości interfejsu użytkownika asystenta

Jeśli potrzebujesz diagramu architektury przed głębokim zagłębieniem się: przejdź do sekcji architektury.

Dlaczego dodawać zmianę głosu do potoku wejściowego

Realtime API to dwukierunkowy kanał audio + tekst. Wysyłasz audio; model transkrybuje, rozumuje i przesyła audio. Wejściowe audio to tylko PCM — API nie ma koncepcji “autentyczne kontra przetworzone”. Oznacza to, że możesz wstrzyknąć dowolne źródło audio.

Powody przetwarzania wejścia przed dotarciem do API:

Spójność osoby. Jeśli pięciu różnych agentów wsparcia obsługuje połączenia, ich naturalne głosy się różnią. Przepuszczenie ich wszystkich przez ten sam profil głosu tworzy jednolity markowany głos dla modelu do “zobaczenia” (i pasowania rejestrów wewnętrznych). To jest oddzielone od wyjściowego głosu TTS — kształtujesz to, co model słyszy od operatora, co wpływa na timing tur i subtelnie na lutowanie tonu modelu.

Aplikacje nauki języka. Uczeń ćwiczący hiszpański może ustawić zmianę głosu, aby spłaszczyć swój akcent w kierunku neutralnego profilu LATAM, zanim audio trafi do Realtime API. Model otrzymuje czystsze fonemy języka docelowego, dokładność ASR się poprawia, a uczeń otrzymuje opinię skalibrowaną do wejścia akcentu natywnego zamiast wejścia z silnym akcentem.

Prywatność i anonimizacja. W wdrożeniu w przedsiębiorstwie operatorzy mogą nie chcieć, aby ich rzeczywiste głosy były przechowywane w dziennikach API. Przetwarzanie głosu przed wywołaniem API oznacza, że przechowywane audio jest transformowane, a nie biometryczny głos mówcy.

Potoki agentów AI. Automaty mogą mieć przypisaną spójną “odcisk palca głosu”, którą model kojarzy z określoną rolą. W orkiestracji agentów wieloczęściowych, różni agenci mogą mieć akustycznie odrębne głosy, nawet jeśli pracują na tym samym sprzęcie.

Jak działa potok audio

Standardowa ścieżka bez zmiany głosu:

Mikrofon → Podsystem audio OS → Przeglądarka/Electron getUserMedia → ścieżka WebRTC → Realtime API

Ze zmianą głosu na etapie wejścia:

Mikrofon → Zmiana głosu → Wyjście wirtualnego mikrofonu → Przeglądarka/Electron getUserMedia → ścieżka WebRTC → Realtime API

Kluczem jest urządzenie wirtualnego mikrofonu. W systemie Windows wirtualne urządzenie audio o małym opóźnieniu zgodne z przechwyciem audio pojawia się na liście urządzeń OS obok fizycznych mikrofonów. Gdy wywołasz navigator.mediaDevices.getUserMedia({ audio: { deviceId: virtualMicId } }), otrzymasz MediaStreamTrack zawierający przetworzone audio. Połączenie WebRTC zużywa tę ścieżkę — OpenAI Realtime API nigdy nie widzi, że pochodzi z urządzenia wirtualnego.

VoxBooster udostępnia dokładnie to: wirtualny mikrofon o małym opóźnieniu przechwytujący audio, który pojawia się w dowolnej przeglądarce lub aplikacji Electron jako standardowe urządzenie wejściowe. Subklonowanie głosu AI i efekty DSP pod 20ms oba zapisują się na to wirtualne wyjście, dzięki czemu możesz przełączać się między nimi w czasie rzeczywistym bez ponownego łączenia sesji WebRTC.

Diagram architektury

┌─────────────────────────────────────────────────────────┐
│  Windows 10/11                                          │
│                                                         │
│  Mikrofon fizyczny ──► Zmiana głosu ──► Urządzenie wirtualnego mikrofonu │
│                    (10-300 ms)      (przechwytywanie audio o małym opóźnieniu)        │
└─────────────────────────────┬───────────────────────────┘
                              │ getUserMedia(deviceId)
                              ▼
┌─────────────────────────────────────────────────────────┐
│  Przeglądarka / Aplikacja Electron                      │
│                                                         │
│  MediaStream ──► RTCPeerConnection                      │
│                  oferta/odpowiedź WebRTC                │
│                  ICE + DTLS-SRTP                        │
└─────────────────────────────┬───────────────────────────┘
                              │ UDP (SRTP)
                              ▼
┌─────────────────────────────────────────────────────────┐
│  OpenAI Realtime API                                    │
│                                                         │
│  VAD → Transkrypcja → Wnioskowanie modelu → Wyjście TTS │
│  (transport WebRTC lub WebSocket)                       │
└─────────────────────────────────────────────────────────┘

Realtime API obsługuje zarówno WebRTC (preferowany dla aplikacji przeglądarki, automatycznie obsługuje jitter i NAT), jak i WebSocket (preferowany dla potoków Node.js po stronie serwera, gdzie bezpośrednio kontrolujesz bufor PCM).

Ustawianie połączenia WebRTC

Ścieżka WebRTC OpenAI Realtime API wymaga efemerycznego tokenu. Typowy przepływ:

Twój backend wywołuje POST /v1/realtime/sessions z kluczem API i zwraca krótkotrwały sekret klienta.
Twój frontend używa tego sekretu do utworzenia RTCPeerConnection z infrastrukturą OpenAI TURN/STUN.
Dodajesz MediaStreamTrack wirtualnego mikrofonu do połączenia peer.
Połączenie przenosi przetworzone audio głosu do modelu.

Minimalny fragment JavaScript:

// 1. Pobierz efemeryczny token z backendu
const { client_secret } = await fetch('/api/realtime-token').then(r => r.json());

// 2. Wylicz urządzenia i znajdź wirtualny mikrofon
const devices = await navigator.mediaDevices.enumerateDevices();
const virtualMic = devices.find(d => d.kind === 'audioinput' && d.label.includes('VoxBooster'));

// 3. Przechwyć przetworzone audio
const stream = await navigator.mediaDevices.getUserMedia({
  audio: { deviceId: virtualMic.deviceId, echoCancellation: false, noiseSuppression: false }
});

// 4. Zbuduj połączenie WebRTC
const pc = new RTCPeerConnection();
pc.addTrack(stream.getAudioTracks()[0]);

// 5. Połącz się z Realtime API
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

const sdpResponse = await fetch('https://api.openai.com/v1/realtime', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${client_secret.value}`,
    'Content-Type': 'application/sdp'
  },
  body: offer.sdp
});

await pc.setRemoteDescription({ type: 'answer', sdp: await sdpResponse.text() });

Uwaga: wyłącz echoCancellation i noiseSuppression w ograniczeniach getUserMedia, gdy zmiana głosu już je obsługuje. Nakładanie przetwarzania szumów na poziomie przeglądarki na wierzchu przetworzonego audio wprowadza artefakty podwójnego przetwarzania.

Budżet opóźnienia w głębi

Zakres 0,5–1,5 sekundy to koperta planowania. Oto jak to zacisnąć:

Etap przetwarzania głosu (10-300 ms). Efekty DSP (wysokość, equalizacja, chorus, reverb) przetwarzają się w czasie rzeczywistym w 10-20 ms. Klonowanie głosu AI wymaga okna lookahead — zazwyczaj 50-150 ms na wyjście pierwszego tokenu — i skaluje się wraz z rozmiarem modelu i dostępnością GPU. Na maszynie bez dyskretnego GPU spodziewaj się 150-300 ms do klonowania AI. Na GPU do gier średniej klasy ten sam model działa w 50-80 ms.

Sieć do API (15-40 ms). WebRTC UDP jest szybszy niż WebSocket TCP dla audio. Użyj regionalnego punktu końcowego API najbliższego użytkownikom — OpenAI kieruje do najbliższego centrum danych automatycznie, ale jeśli jesteś proxy przez swój backend, umieść backend blisko punktu końcowego API.

Wnioskowanie Realtime API (300-800 ms). To jest dominujący termin i nie jest kontrolowany przez użytkownika. gpt-4o-realtime-preview działa szybciej niż większe modele. Ustawienie krótkich max_response_output_tokens zmniejsza czekanie na pierwszy token audio. Korzystanie z turn_detection: { type: 'server_vad' } z kalibrowanym threshold unika fałszywych zakończeń tur, które powodują przedwczesne wnioskowanie.

Wyjście transmisji (15-40 ms). API przesyła strumieniowo fragmenty audio w miarę ich generowania. Pierwszy fragment audio zazwyczaj pojawia się w ciągu 300-500 ms od wykrycia ukończenia tury. Jeśli również stosuje transformację głosu do wyjścia, dodaj 10-50 ms na tym etapie.

Tabela przypadków użycia i osoby

Przypadek użycia	Profil głosu wejścia	Dlaczego to ma znaczenie
Bot wsparcia klienta z marką	Neutralny profesjonalny głos	Spójny markowy głos niezależnie od operatora
Tutor nauki języka	Spłaszczenie akcentu języka docelowego	Lepszy ASR na wyjściu ucznia
AI towarzysz do gier	Głos fantasy/postaci	Immersja; towarzysz brzmi inaczej niż gracz
Agent AI przedsiębiorstwa	Odcisk palca głosu przypisany roli	Potoki wieloagentowe, zróżnicowanie audytu
Operator chroniący prywatność	Anonimowy głos	Ochrona biometryczna w zarejestrowanym audio
Asystent dostępności	Normalizacja jasności mowy	Czystsze wejście poprawia ASR dla dysartrycznego mowy

Obsługa detektora aktywności głosu

VAD z Realtime API określa, kiedy tura mówcy się kończy i wyzwala wnioskowanie modelu. Ze zmienianym audio może pojawić się kilka problemów:

Fałszywe alarmy z ogonem reverbu. Ciężki reverb rozszerza kopertę audio po zatrzymaniu mówcy. VAD może zinterpretować to jako kontynuowany mowy i opóźnić wykrywanie tury. Rozwiązanie: zmniejsz czas rozpadu reverbu lub dodaj małe silence_duration_ms do konfiguracji VAD.

Efekty wysokości i próg energii. Ekstremalne przesunięcia wysokości przesuwają energię do pasm częstotliwości, na których nie wytrenowano modelu energii VAD. Jeśli VAD pominą początek mowy, obniż parametr threshold w konfiguracji turn_detection.

Klonowanie AI lookahead i jitter. Jeśli model klonowania głosu wprowadza zmienność opóźnienia (jitter), strumień audio ma nieregularny czas pakietów. Może to spowodować przepełnienie bufora jitter na ścieżce WebRTC. Złagodź, dodając bufor jitter 50 ms po stronie wysyłania, lub używając transportu WebSocket, gdzie dokładnie kontrolujesz tempo zapisu PCM.

Do testowania fallbacku opartego na Whisper — przydatne podczas sprawdzania, czy przetworzone audio daje czystą transkrypcję przed wdrożeniem pełnej integracji Realtime API — możesz podać wyjście wirtualnego mikrofonu do lokalnego modelu Whisper i sprawdzić transkrypcje. To jest szybsze do iteracji niż wykonywanie Live API call.

Budowanie strony wyjścia

Zmiana głosu na wejściu to połowa obrazu. Aby mieć asystenta zablokowanego osobu, chcesz również, aby wyjście audio modelu przeszło przez transformację głosu, zanim dotrze do głośników użytkownika. To jest prostsze, ponieważ jest przetwarzaniem końcowym: przechwytujesz wyjście MediaStreamTrack, przepuszczasz go przez audio worklet lub lokalną łańcuch DSP i kierujesz na głośniki.

Typowe wzory:

Przepuść wyjście przez regulację wysokości, aby pasowała do rejestru osoby
Zastosuj spójny profil equalizacji (wzmocnij obecność, lekkie wycofanie ciepła)
Dodaj subtelny reverb pokojowy dla postaci, które mają brzmieć w fizycznej przestrzeni

Połączony potok wygląda wtedy:

[Mikrofon operatora] → Zmiana głosu → Wirtualny mikrofon → Realtime API → Wyjście TTS → Efekty głosu wyjścia → Głośniki

Lista kontrolna integracji

Przed wysłaniem integracji produkcji:

Potwierdź, że urządzenie wirtualnego mikrofonu pojawia się w enumerateDevices() i przetrwa odświeżanie przeglądarki
Wyłącz anulowanie echa i tłumienie szumu na poziomie przeglądarki (zmiana głosu je obsługuje)
Zmierz opóźnienie przetwarzania głosu na percentylu sprzętu docelowego (p95, nie średnia)
Przetestuj zachowanie VAD ze swoim specyficznym profilem głosu — sprawdź pominięte starty tur i fałszywe końce
Ustaw max_response_output_tokens, aby ograniczyć opóźnienie pierwszego tokenu audio dla krótkich wymian
Dodaj graceful degradation: jeśli wirtualny mikrofon zniknie (użytkownik zamknął VoxBooster), wróć do fizycznego mikrofonu
W przypadku produkcji, pośrednik żądania tokenu efemerycznego poprzez backend — nigdy nie ujawniaj klucza API OpenAI w przeglądarce

Aby uzyskać bardziej głębokie wprowadzenie do samego Realtime API, zobacz dokumentację OpenAI Realtime API. Artykuł WebRTC Wikipedia jest dobrym odniesieniem do zrozumienia warstwy transportu, jeśli jesteś nowy.

Co VoxBooster dodaje do stosu

VoxBooster to aplikacja do przetwarzania głosu Windows 10/11, która mieści się w tej architekturze na warstwie wirtualnego mikrofonu. Specyficzne właściwości istotne dla integracji Realtime API:

Wirtualny mikrofon o małym opóźnieniu przechwytujący audio bez sterownika jądra — pojawia się na listach urządzeń przeglądarki natychmiast po instalacji, bez ponownego uruchomienia
Ścieżka DSP poniżej 20ms dla wysokości, equalizacji i efektów — utrzymuje budżet przetwarzania głosu wystarczająco niski, aby całkowita podróż tam i z powrotem pozostała poniżej 1 s na większości sprzętu
Klonowanie głosu AI poniżej 300ms uruchamiane na CPU lub GPU — bez zależności chmury, głos pozostaje lokalny
Zintegrowane tłumienie szumu oznacza, że możesz bezpiecznie wyłączyć przetwarzanie szumów na poziomie przeglądarki bez pogorszenia jakości audio

VoxBooster jest dostępny za $6.99/miesiąc lub R$29,90/miesiąc — jedna licencja obejmuje pełny zestaw funkcji, w tym wirtualny mikrofon, klonowanie AI, soundboard i tłumienie szumu.

Powiązane czytanie

Budowanie na OpenAI Realtime API jest naprawdę ekscytujące, a potok wejścia audio jest jedną z najmniej udokumentowanych części stosu. Jeśli eksperymentujesz z głosami osoby, nauczycielami języka lub zróżnicowaniem agentów, podejście wirtualnego mikrofonu opisane tutaj jest ścieżką o najmniejszym tarciu na Windows — bez przetwarzania audio po stronie serwera, bez opóźnienia z dodatkowego skoku sieciowego, po prostu przetworzone audio trafia bezpośrednio do ścieżki WebRTC.

Pobierz VoxBooster i spróbuj wirtualnego mikrofonu z Realtime API. Konfiguracja zajmuje mniej niż pięć minut.

Najczęściej zadawane pytania

Czy mogę używać zmieniającego głos z OpenAI Realtime API? Tak. Realtime API otrzymuje audio poprzez standardową ścieżkę mediów WebRTC lub surowy strumień PCM. Jeśli zmiana głosu tworzy wirtualne urządzenie mikrofonowe, to urządzenie wirtualne przekazujesz jako źródło wejścia audio podczas nawiązywania połączenia. API nie ma sposobu na rozróżnienie przetworzonego i nieprzetworzonego audio.

Jakie jest całkowite opóźnienie podczas łączenia zmieniającego głos z Realtime API? Spodziewaj się 0,5–1,5 sekundy obustronne w typowych wdrożeniach. Przetwarzanie głosu dodaje 10–300 ms w zależności od typu efektu. Sam Realtime API przyczynia się 300–800 ms do wnioskowania modelu i generowania odpowiedzi. Podróże sieciowe dodają kolejne 30–80 ms.

Czy OpenAI Realtime API obsługuje WebRTC natywnie? Tak. OpenAI dodała natywną obsługę WebRTC obok oryginalnego transportu WebSocket. WebRTC jest preferowaną ścieżką dla aplikacji opartych na przeglądarce i aplikacji Electron, ponieważ automatycznie obsługuje NAT traversal, buforowanie jitter i odzyskiwanie utraty pakietów.

Jakie opóźnienie zmieniającego głos jest akceptowalne, zanim Realtime API odrzuci audio? Realtime API nie odrzuca audio na podstawie opóźnienia — przetwarza to, co otrzymuje. Praktycznym pułapem jest doświadczenie użytkownika: powyżej około 300 ms opóźnienia przetwarzania głosu opóźnienie mówcy do modelu staje się zauważalne podczas naturalnych tur rozmowy.

Czy mogę użyć tego ustawienia dla bota wsparcia klienta z markowym głosem? Tak, i jest to jeden z najmocniejszych przypadków użycia. Wysyłasz audio operatora przez zmianę głosu, która mapuje go na spójną markową osobę, następnie podajesz wyjście do Realtime API.

Czy to działa w przeglądarce bez aplikacji pulpitu? W przeglądarce na Windows wirtualny mikrofon o małym opóźnieniu oparty na przechwytywaniu audio pojawia się na liście urządzeń przeglądarki. Czyste implementacje internetowe mogą również przetwarzać audio za pośrednictwem Web Audio API i bezpośrednio podawać przetworzony strumień do ścieżki WebRTC bez urządzenia wirtualnego.

Co się dzieje z detektorem aktywności głosu Realtime API, gdy zmieniony jest głos? VAD pracuje na amplitudzie i cechach spektralnych przychodzącego audio. Większość efektów głosowych nie wpływa znacząco na dokładność VAD. Ciężkie efekty, takie jak ekstremalne obniżenia wysokości, mogą zdezorientować próg VAD — dostosuj czułość lub dodaj ręczny czas trwania ciszy, jeśli napotkasz pominięte granice tur.