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.
Proposal
Expose an optional
chunk_size_msargument ondeepgram.STTv2so 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._runsetssamples_per_channeltosample_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
EndOfTurnby 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.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
EndOfTurnevent. 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:
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 hadtrigger: 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.