Day 07 開始把整條語音 Pipeline 往 Streaming 架構調整後，AI 已經可以更早開始回答。

但實際對話時還有一個問題：

只要 AI 開始說話，就只能等它講完。

真人對話並不是這樣。

如果對方講錯、講太多，或我突然想到別的事情，通常會直接插話。

所以今天要加入另一個很重要的語音互動功能：

Barge-in。

Barge-in 是什麼？

Barge-in 指的是：

AI 正在說話時，使用者仍然可以直接開口打斷。

原本流程比較像：

AI Speaking
↓
等待播放完成
↓
Listening

加入 Barge-in 後則變成：

AI Speaking
↓
使用者重新開口
↓
VAD 偵測 Speech Start
↓
Stop Playback
↓
Clear Playback Queue
↓
取消後續 TTS / LLM Streaming
↓
Listening
↓
STT
↓
重新回答

這樣才比較接近真正的雙向語音對話。

VAD 再次派上用場

前面使用 VAD，主要是判斷：

使用者開始說話
使用者停止說話

今天它多了一個用途：

AI 說話期間，也持續監聽使用者是否重新開口。

當系統處於 SPEAKING 狀態，但 VAD 又偵測到新的 Speech Start，就可以觸發 Barge-in。

打斷不只是停止聲音

一開始很容易以為，只要：

player.stop()

就完成了。

但 Streaming Pipeline 背後可能還有：

LLM
↓
文字 Chunk
↓
TTS
↓
Playback Queue

所以 Barge-in 觸發後，還需要：

Stop Playback
↓
Clear Queue
↓
取消後續 TTS
↓
中止 LLM Streaming
↓
切回 Listening

否則即使目前的聲音停下來，Queue 裡剩下的語音還是可能繼續播放。

AI 會不會打斷自己？

AI 播放語音時，麥克風也可能收到喇叭聲音，讓 VAD 誤判成使用者重新開口。

第一版先透過：

• Speech threshold
• 最短語音持續時間
• Cooldown

降低誤觸。

之後如果要再提高穩定性，可以加入 Acoustic Echo Cancellation（AEC）處理回音。

Barge-in latency

今天主要觀察：

User Speech Start → AI Audio Stop

也就是使用者開始插話後，AI 多快停止播放。

例如：

User Speech Start : 12.430s
AI Audio Stop     : 12.570s

Barge-in Latency  : 140 ms

這個時間越短，使用者就越不容易感覺 AI 還在搶話。

今天完成了什麼？

今天把原本只能等待 AI 說完的流程，加入了即時打斷機制。

現在語音互動變成：

AI Speaking
↓
User Barge-in
↓
Stop Playback
↓
Clear Queue
↓
Listening
↓
重新辨識與回答

AI Companion 不再只能「你一句、我一句」輪流說話，而開始具備更接近真人對話的互動方式。

下一步：Memory

目前已經完成：

STT
↓
LLM
↓
Streaming / Chunked TTS
↓
Barge-in

下一步準備進入另一個核心：

Memory。

讓 AI 不只是能聽、能說、能被打斷，而是真的開始「記得你」。