Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Expose configurable outgoing audio chunk duration for Deepgram Flux

Abierto Apto para principiantes
  • ¿Algo no está bien?
#7,204 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
74/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
python
Área
audio-video-rtc

Línea de trabajo

Empieza en el paquete livekit-plugins-deepgram: encuentra el constructor de deepgram.STTv2 y el bucle _run de SpeechStreamv2 donde samples_per_channel se establece en sample_rate // 20 (el valor predeterminado de 50 ms). Pasa un argumento opcional chunk_size_ms de entero positivo para que solo cambie esa aritmética de lotes, manteniendo el valor predeterminado y el vaciado del chunk parcial. Añade un test de WebSocket falso que verifique los tamaños de los mensajes salientes para 50 ms y 80 ms; se da por terminado cuando el comportamiento predeterminado no cambia y la nueva opción produce lotes de 80 ms. Ten en cuenta que el issue pregunta al maintainer si la API encaja, así que confirma la aceptación antes de invertir mucho esfuerzo.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Python
Estrellas
14.6k
Forks
3.9k
Merge medio
2 d 6 h
PR fusionados (30 d)
153

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de livekit/agents

Todos los issues de livekit/agents

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.