Expose configurable outgoing audio chunk duration for Deepgram Flux
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 2/5
- 見積もり時間
- 1〜3時間
- 初心者へのやさしさ
- 74/100
- issue の種類
- 機能追加
- 明瞭さ
- 明確に書かれている
- 活発さ
- 活発
- 技術スタック
- python
調査の方向性
livekit-plugins-deepgram パッケージから始める: deepgram.STTv2 のコンストラクタと、samples_per_channel が sample_rate // 20（50 ms のデフォルト）に設定される SpeechStreamv2._run ループを見つける。オプションの正の整数の引数 chunk_size_ms を通して、変更されるのはそのバッチ処理の算術だけにし、デフォルトと部分チャンクのフラッシュは維持する。50 ms と 80 ms に対する送信メッセージサイズを検証するフェイク WebSocket テストを追加する。完了の条件は、デフォルトの挙動が変わらず、新しいオプションが 80 ms のバッチを生成すること。なお、この issue は API が適合するかをメンテナーに尋ねているので、多大な労費を投じる前に承認を確認しておくこと。
索引モデルが issue の本文から書いたものです。
説明
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.
- 主要言語
- Python
- スター
- 14.6k
- フォーク
- 3.9k
- 平均マージ
- 2日 6時間
- マージ済み PR（30日）
- 153
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
livekit/agents のほかの issue
-
BM25SearchStrategy (the default) never matches underscore-joined terms in tool descriptions or param descriptions対応中かも @BlueX888 が今日担当しました。 オープン
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
livekit/agents#7727 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
Assistant markup is stripped from chat history when expressive mode is off対応中かも @ShivamSharma43 が 4 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
docs: openai.LLM vs openai.responses.LLM for HTTP OpenAI-compat hosts再び着手できるかも @AbarnaaSree が 43 日前に担当しましたが、オープン中のプルリクエストはありません。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
livekit/agents#7022 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
[Plugin] livekit-plugins-sherpa: local TTS on sherpa-onnx (Kokoro, Kitten, Piper)対応中かも @mahimairaja が今日担当しました。 オープン
難易度 4/5 3〜5日 初心者へのやさしさ 25/100
メンテナーはふだん 1 日以内に返信
-
[Plugin] livekit-plugins-sherpa: local STT on sherpa-onnx (streaming + batch)対応中かも @mahimairaja が今日担当しました。 オープン
難易度 5/5 1週間以上 初心者へのやさしさ 20/100
メンテナーはふだん 1 日以内に返信
似ている issue
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
lugassawan/swe-workbench#799 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
vllm-project/vllm#61131 ·
メンテナーはふだん 1 日以内に返信
-
Non-string form field names raise AttributeError when files are attached対応中かも @nightcityblade が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
kubernetes-client/python#2735 ·
メンテナーはふだん 1 日以内に返信
-
desktop help wanted test
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信