Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Expose configurable outgoing audio chunk duration for Deepgram Flux

Aperta Adatta ai principianti
  • Qualcosa non va?
#7,204 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
74/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
python
Ambito
audio-video-rtc

Direzione di ricerca

Inizia nel pacchetto livekit-plugins-deepgram: trova il costruttore di deepgram.STTv2 e il ciclo _run di SpeechStreamv2 dove samples_per_channel viene impostato su sample_rate // 20 (il default di 50 ms). Fai passare un argomento opzionale chunk_size_ms a intero positivo in modo che cambi solo quell'aritmetica di batching, mantenendo il default e il flush del chunk parziale. Aggiungi un test con un WebSocket falso che verifichi le dimensioni dei messaggi in uscita per 50 ms e 80 ms; si può considerare concluso quando il comportamento di default è invariato e la nuova opzione produce batch da 80 ms. Nota che l'issue chiede al maintainer se l'API sia adatta, quindi conferma l'accettazione prima di investire troppo.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Proposal

Expose an optional chunk_size_ms argument on deepgram.STTv2 so applications can configure outgoing PCM WebSocket batching. Keep the existing 50 ms default; allow opting into 80 ms without replacing the plugin's send loop.

In the tested Deepgram plugin version (1.6.1), SpeechStreamv2._run sets samples_per_channel to sample_rate // 20. Deepgram's Flux quickstart recommends 80 ms chunks (2,560 bytes for mono linear16 at 16 kHz).

Updated evidence: isolated Flux benchmark

We repeated the comparison with 24 direct WebSocket trials from a LiveKit Cloud worker in us-east, removing RTC media, VAD, LiveKit endpointing, LLM, and TTS from the measured path. This follow-up tests the effect of PCM batching on observed Flux EOT latency.

The primary metric is the interval from acoustic speech end on a real-time-paced PCM timeline to receipt of Flux EndOfTurn by the worker. Acoustic speech end is the end of the last 10 ms window with normalized RMS above 0.025. Both timestamps use the same worker-side monotonic clock.

Synthetic utterance Mean EOT latency, 50 ms chunks Mean EOT latency, 80 ms chunks Difference, 80 minus 50
“Please tell me where to put the blue notebook.” 437.5 ms 400.7 ms −36.8 ms
“Please put the blue notebook.” 446.2 ms 418.8 ms −27.5 ms
“on the wooden table next to the lamp.” 532.4 ms 523.5 ms −8.9 ms
All trials 472.0 ms 447.7 ms −24.4 ms (about 5.2%)

We used three distinct prerecorded utterances. Each utterance was sent to Flux eight times: four times using 50 ms audio chunks and four times using 80 ms audio chunks.

A trial means sending one complete utterance over a fresh WebSocket connection and measuring the time from its acoustic speech end to receipt of Flux’s EndOfTurn event. The 50 ms and 80 ms values describe the duration of audio in each WebSocket message—not the duration of the utterance or the interval between trials.

For a given utterance, every trial used identical PCM audio, including the same leading and trailing silence. Only the outgoing chunk size changed.

We organized the trials into two blocks:

Block First trial Second trial Third trial Fourth trial
Block 1 50 ms 80 ms 80 ms 50 ms
Block 2 80 ms 50 ms 50 ms 80 ms

We used this counterbalanced order to reduce the influence of changes over time, such as network conditions or provider load. Running all 50 ms trials first and all 80 ms trials afterward could favor whichever condition happened to run during a faster period. Reversing the order in the second block gives both chunk sizes exposure to earlier and later positions.

This reduces ordering bias

80 ms was faster in 8 of 12 adjacent matched pairs; the median paired difference was −23.5 ms. All 24 trials produced exactly one EndOfTurn, none before the acoustic boundary. Final transcripts matched across conditions for each utterance, and all EOT events had trigger: model.

Suggested scope

A constructor-only positive integer duration, documented in milliseconds, used solely by the local audio batching loop. Preserve the 50 ms default and existing partial-chunk flush behavior.

Would this API fit the plugin? A small draft implementation with fake-WebSocket tests can serve as a concrete proposal.

Lingua principale
Python
Stelle
14.6k
Fork
3.9k
Merge medio
2g 6h
PR unite (30g)
153

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di livekit/agents

Tutte le issue di livekit/agents

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.