本文件說明 Fuchsia 中音訊驅動程式公開的音訊串流介面。內文是供使用者和駕駛人參考的參考資料，並明確定義駕駛人必須實作的介面合約，使用者也必須遵守。
總覽
音訊串流是由驅動程式庫服務發布的裝置節點，可供應用程式在 Fuchsia 裝置上擷取或算繪音訊。系統中的每個串流 (輸入或輸出內容) 都代表裝置可能接收或傳輸的數位音訊資訊串流。串流是動態的，隨時可能由系統建立或刪除。在任何指定時間點存在哪些串流，以及這些串流的生命週期屬於音訊政策和轉碼器管理問題，不會在此文件中討論。此外，音訊輸出串流中顯示的資訊專屬於串流的應用程式擁有者。混合音訊並非由音訊串流介面提供。
定義
| 字詞 | 定義 |
|---|---|
| 範例 | 由單一喇叭轉譯，或由單一麥克風在同一時間擷取的音訊。 |
| LPCM | 線性脈衝程式碼調用。所有 Fuchsia 未壓縮音訊串流中呈現的音訊樣本具體呈現方式。LPCM 音訊樣本是即時的音訊信號振幅，且編碼音訊的數值會線性分佈於轉譯或擷取裝置的振幅等級。這與 A-law 和 μ-law 編碼不同，後者俱有從數值到振程度的非線性對應。 |
| 頻道 | 在音訊串流中，單一喇叭會顯示的部分資訊，或由單一麥克風在串流中擷取的資訊子集。 |
| 頁框 | 單一即時擷取/轉譯音訊串流的每個管道的一組音訊樣本。 |
| 畫面更新率 | a.k.a.「取樣率」。產生或消耗音訊影格的速率 (以 Hz 為單位)。常見的取樣率包括 44.1 KHz、48 KHz、96 KHz 等。 |
| 用戶端或使用者或應用程式 | 這些詞彙在本文件中可以交替使用。也就是使用這些介面與音訊驅動程式庫/裝置通訊的模組。 |
基本操作
使用透過頻道傳送的訊息會與音訊串流裝置進行通訊。應用程式會開啟串流的裝置節點，並發出 FIDL 要求來取得管道。取得管道後，裝置節點可能會關閉。所有與串流的後續通訊都是透過管道進行。
串流管道適用於大多數的命令和控制工作，包括：
- 功能檢查
- 格式協商
- 硬體增益控制
- 確定外板延遲時間
- 電源偵測通知
- 存取權控管能力偵測和訊號
為了在串流中實際傳送或接收音訊資訊，您必須先設定要使用的特定格式。成功 CreateRingBuffer 作業的回應會包含新的「ring-buffer」管道。環形緩衝區管道可用來從串流要求共用緩衝區 (以 VMO 的形式提供)，這個緩衝區可對應至應用程式的位址空間，並視情況用於傳送或接收音訊資料。一般來說，在環形緩衝區管道上執行的作業包括：
- 要求共用緩衝區
- 開始及停止播放及擷取串流
- 接收播放和擷取進度的通知
- 在音訊輸出時鐘的基因和支援單音器時鐘的振盪器不同時，接收時鐘復原資訊。
作業詳細資料
裝置節點
音訊串流裝置節點必須由驅動程式使用下表提供的通訊協定預先處理器符號發布。這會導致串流裝置節點發布至表格指定的位置。應用程式可以監控這些目錄，以便在驅動程式發布的新串流時加以探索。
| 串流類型 | 通訊協定 | 位置 |
|---|---|---|
| 輸入 | ZX_PROTOCOL_AUDIO_INPUT |
/dev/class/audio-input |
| 輸出內容 | ZX_PROTOCOL_AUDIO_OUTPUT |
/dev/class/audio-output |
建立串流管道
開啟裝置節點後，用戶端應用程式可能會取得串流管道，以便使用 fuchsia.hardware.audio.Device/GetChannel FIDL 訊息進行後續通訊。
串流管道的用戶端終止
用戶端可隨時呼叫串流管道上的 zx_handle_close(...) 來終止與串流的連線。驅動程式必須關閉任何透過這個串流管道建立的有效環形緩衝區通道，且必須每次嘗試以安全的方式退出所有正在進行的串流作業。
在串流和鈴聲緩衝區管道上收發訊息
凡是可透過串流和環形緩衝區管道傳送或接收的訊息和訊息酬載，都是在 stream_config.fidl 和 ring_buffer.fidl 中定義。訊息可透過 zx_channel_write(...) 系統呼叫傳送至驅動程式庫。如果預期收到回應，可能會使用 zx_channel_read(...) Syscall 讀取。不過，最佳做法是使用 zx_port_queue(...) 系統呼叫將頻道 通訊埠的封包排入佇列，並使用 zx_port_wait(...) 系統呼叫判斷您的一組管道何時會有讀取訊息 (預期回應或非同步通知)。有些語言有繫結，方便傳送及接收 FIDL 訊息。尤其是 C++ 驅動程式的 SimpleAudioStream 程式庫，可協助建立 C++ 的驅動程式，這個程式庫會使用新的 C++ 繫結傳送及接收 FIDL 訊息。
格式協商
範例格式
與 Format 相關的通訊協定訊息可讓驅動程式庫列出支援的格式給用戶端。支援的格式可能包含多種費率、每樣本位元等。每個驅動程式庫都會宣傳可支援的內容，且用戶端要求每個驅動程式庫使用的格式。
為了找出特定驅動程式庫支援哪些格式，用戶端會使用 GetSupportedFormats 函式。駕駛人會使用 SupportedFormats 向量回覆，其中每個 SupportedFormats 都包含一個具有以下內容的 PcmSupportedFormats：
- 管道數量的向量。這會列出驅動程式庫支援的通道數量，例如
<2,4,6,8>。如果驅動程式支援兩個或四個管道，就會回報具有兩個元素的向量<2,4>。必須依遞增順序排列。 - 範例格式的向量，例如
PCM_SIGNED。 - 費率向量。畫面更新率，例如 44100、48000 和 96000。必須依遞增順序排列。
- 每項樣本的位元組數。必須依遞增順序排列。
- 每個樣本位元的向量。樣本寬度可能小於可用位元組總數，例如 4 位元組樣本中的 24 位元。必須依遞增順序排列。
當驅動程式庫支援的所有組合都無法以一個 PcmSupportedFormats 描述時，驅動程式庫會在傳回的向量中傳回多個 PcmSupportedFormats。舉例來說，如果一個 PcmSupportedFormats 允許在 48KHz 取得 16 或 32 位元樣本，以及 96KHz 的 16 位元樣本，而非 96KHz 的 32 位元樣本，則驅動程式庫會傳回 2 PcmSupportedFormats：<<16bits,32bits>,<48KHz>> 和 <<16bits>,<96KHz>>。為求簡單起見，本範例會忽略每個樣本速率和位元以外的參數。如果驅動程式庫支援 48 或 96KHz 的 16 或 32 位元樣本，驅動程式庫會使用 1 PcmSupportedFormats 回應：<<16bits,32bits>,<48KHz,96KHz>>。
此外，系統會假設每個樣本的位元一律小於或等於每個樣本 8 * 個位元組。因此，驅動程式庫可以回報 <<2bytes_per_sample,4bytes_per_sample>,<16bits_per_sample,32bits_per_sample>>，但這並不表示 2 位元組樣本中每個樣本 32 位元有效，只能指定 3 個有效組合：
- 具備 16 個有效位元的 2 位元組通道
- 具備 32 個有效位元的 4 位元組樣本
- 具備 16 個有效位元的 4 位元組樣本
用戶端會根據驅動程式庫在 GetSupportedFormats 回覆中提供的資訊、用戶端支援的內容和任何其他要求，指定與 CreateRingBuffer 函式搭配使用的格式。這個函式採用的參數會指定以下項目：
- 多個頻道。這是緩衝區中可用的頻道數量。
- 要使用的頻道位元遮罩。這些是緩衝區中的管道，供驅動程式庫使用。舉例來說，如果是立體聲，就必須是啟用 2 位元
0x3的位元遮罩。也就是說，兩者都會使用 0 和 1 聲道。 - 範例格式。
- 畫面更新率。
- 每項樣本的位元組數。
- 每個樣本的數量位元。
注意：
- 根據預設，系統會假設多位元組範例格式是使用主機端字元。
PCM_FLOAT編碼會特別使用 IEEE 754 浮點表示法。- 根據預設，系統會假設非浮點 PCM 編碼使用兩組互補整數表示。例如，16 位元 PCM 範例格式的位元值的範圍從 [0x8000, 0x7FFF] 開始，並以 0x0000 表示沒有喇叭延遲。如果使用
PCM_UNSIGNED樣本格式，位元值的範圍從 [0x0000, 0xFFFF] 開始，0x8000 代表零延遲。 - 在大型管道中 (例如 32 為 20 或 24 位元) 編碼較小的樣本大小時，系統會忽略 32 位元容器中最重要的位元，並忽略最顯著的位元 (靠左對齊)。例如，20 位元樣本會對應到 [12,31] 這個範圍 (3 位元的 [0,11] 範圍內)。
設定所需的串流格式
為選取串流格式，應用程式會透過串流管道傳送 CreateRingBuffer 訊息。在訊息中，應用程式會指定要使用的格式。
用戶端會指定用於執行串流的新環形緩衝區管道。如果先前建立的環形緩衝區管道已建立完成，且仍在使用中，驅動程式庫必須關閉通道，並盡可能在過程中妥善退出所有正在進行的串流作業。
判斷外部延遲時間
音訊串流的外部延遲時間的定義是，輸出音訊從系統互連網路傳送至喇叭本身傳輸的時間，或傳入音訊從麥克風傳輸到系統互連網路的時間長度。例如，假設外部轉碼器使用 TDM 互連網路連線至系統：如果這個互連網路在 TDM 影格接收到顯示該影格之間出現 4 個影格延遲，則這個音訊路徑的外部延遲時間等於 4 個音訊影格的時間長度。
外部延遲會在對 WatchDelayInfo 回應的 DelayInfo 回應的 external_delay 欄位中回報。駕駛應盡力準確地回報驅動程式庫知道的所有延遲來源總數。有關延遲的資訊，通常可在轉碼器規格書中找到；使用 Intel HDA 或 USB Audio 等通訊協定，以動態方式回報為轉碼器的屬性；使用 HDMI 或 DisplayPort 互連網路時，也可透過 EDID 等機制，由下游裝置回報。
正在判斷開啟延遲時間
音訊串流的 turn_on_delay 的定義是，在發出 Start 指令後，系統可能需要在環形緩衝區上實際開始播放音訊樣本所需的時間，或是在 Start 指令執行之後，將麥克風的音訊記錄到環形緩衝區。舉例來說，如果我們已將外部轉碼器連接到系統，並關閉該轉碼器以節省電力，則在系統發出 Start 指令後，提供環形緩衝區的驅動程式庫會回應 start_time，指出環形緩衝區上的位置開始移動，音訊樣本開始傳送到外部轉碼器的時間。不過，如果採用較低電源模式 (請參閱上文的 Determining external latency)，外部轉碼器可能仍會保持開啟。external_delayRingBufferProperties 資料表中指定的 turn_on_delay 是驅動程式庫的最佳最大限度預估值，用來預估外部轉碼器實際輸出音訊樣本所需的時間。延遲也可能是由於其他原因所造成，例如，在增加延遲的情況下內建轉碼器，以免出現故障；或者，如果驅動程式庫抽象了藍牙通訊，使得遠端裝置開始播放音訊樣本的延遲。由於 turn_on_delay 是估算上限，音訊可能會在 turn_on_delay 傳遞之前開始播放或擷取，因此如果無法取得播放或擷取的初始音訊樣本，就必須將延遲時間納入考量。
external_delay 代表音訊取樣傳送至喇叭或麥克風延遲的時間長度。turn_on_delay 不會延遲音訊樣本，也不會指出任何緩衝處理，而是指出音訊樣本可能實際沒有播放/錄製的時間長度。turn_on_delay 不會影響呈現時間的計算結果，但會影響簡報是否進行。就播放而言，我們可以視覺化呈現這些延遲到揚聲器中的延遲情形，如下所示：
|<--- external delay --->|
|S|--|T|----------------------|P|----|O|
|<------- turn on delay ------->|
其中 S 表示核發 Start 的時間，T 表示環形緩衝區中的位置開始移動的時間，也就是從 Start 指令傳回的 start_time。P 表示在揚聲器中的顯示時間，O 表示擴大器完成開啟且可以聽到音訊的時間。由於 O 晚於 P，因此 turn_on_delay 會影響揚聲器的實際呈現方式。
隨著時間的推移，我們能夠以視覺化方式呈現升級下方的環形緩衝區 C 上的目前位置；現在，在擴大器開啟 O 的 P 時，音箱中會顯示樣本。
|<--- external delay --->|
|S|--|T|---------|C|-----------------|O|--|P|
|<------- turn on delay ------->|
|<--- external delay --->|
|S|--|T|-----------------------------|O|-|C|---------------------|P|
|<------- turn on delay ------->|
硬體增益控制
硬體獲得控制能力報告
為了判斷串流的增益功能 (如果尚未建立)，應用程式會透過串流管道傳送 GetProperties 訊息。這則訊息不需要參數。駕駛人會透過 StreamProperties 回覆，包括取得其他功能。無論串流硬體是否具有任何增益控制功能，所有串流驅動程式都必須回應這則訊息。所有增益值都會以 dB 的 32 位元浮點數表示。
駕駛人會使用代表目前串流取得控制能力的值來回應這則訊息。目前的增益設定會以表示串流是否可以靜音的布林值表示；布林值，表示串流是否可以啟用 AGC、最小與最大增益設定及 gain_step_db。gain_step_db 代表最小化增量值，可控制從最小增益值的數量。
舉例來說，如果擴大器各有 5 步，每個增重步驟分別為 7.5 dB 和 0 dB，則代表範圍範圍 (-30.0、0.0) 和步驟大小 7.5。能夠功能持續增益控制功能的擴大器可能會將步數大小編碼為 0.0。
無論忽略功能為何，固定營利串流的驅動程式必須回報最小和最大增益為 (0.0, 0.0)。在此情況下，gain_step_db 表示無意義，但駕駛應回報為 0.0。
設定硬體增益控制等級
如要變更串流目前的取得設定，應用程式會透過串流管道傳送 SetGain 訊息。此訊息包含 GainState 參數，表示要設定的取得參數，包括應套用至串流、靜音和啟用 AGC 的 dB 增益。
假設要求有效，驅動程式應將要求四捨五入至最接近的支援增益步大小。舉例來說，如果串流可以控制從 -60.0 到 0.0 dB 範圍的增益，且使用 0.5 dB 的增益步數，則要求將增益設為 -33.3 dB 的要求應會套用 -33.5 的增值。向同一串流中獲得 -33.2 dB 的要求時，應會獲得 -33.0 的增值。
接收狀態通知
用戶端可以使用 WatchGainState 指令，要求串流傳送發生狀態變更的非同步通知。驅動程式會回應用戶端傳送的第一則 |WatchGainState|，但不會回應後續的用戶端 |WatchGainState| 呼叫，直到取得最近回報的狀態變更為止。
插頭偵測
除了因回應匯流排連線或與匯流中斷連線而發布/取消發布的串流之外，串流也可以在任何特定時間點接上電源或未插上電源。舉例來說，一組 USB 耳機可能會在連線至 USB 時發布新的輸出串流，但也可以選擇從插頭偵測觀點「有線」。另一個使用標準 3.5mm phono 插孔的 USB 音訊轉接器可能會在透過 USB 連線時發布輸出串流，但選擇變更已插上/未插上電源的類比裝置，並透過 3.5 公釐耳機插孔拔除類比裝置的插頭。
可查詢目前插上或未接上電源的串流狀態，以及註冊插入外掛程式狀態變更的非同步通知 (如果支援的話)，是透過插頭偵測訊息來處理。
插頭偵測功能
為了判斷串流的插頭偵測功能 (如果尚未偵測)，應用程式會透過串流管道傳送 GetProperties 指令。驅動程式會使用 StreamProperties 回應，包括 plug_detect_capabilities 中其他欄位的外掛程式偵測功能。
目前定義的有效外掛程式偵測功能旗標如下：
- 當串流硬體被視為「有線」時，系統會設定
HARDWIRED。換句話說，只要裝置發布，串流就算是已連線。例如，一組內建喇叭、一對 USB 耳機，或沒有插頭偵測功能的可插式音訊裝置。 - 當串流硬體能夠以非同步方式偵測裝置插座狀態變更時，就會設定
CAN_ASYNC_NOTIFY，並在用戶端要求這些通知時傳送通知訊息。
電源狀態通知
如果 StreamProperties 中的驅動程式庫傳送 CAN_ASYNC_NOTIFY 標記，用戶端可以使用 WatchPlugState 指令，要求串流傳送插入狀態變更的非同步通知。例如，未設定 CAN_ASYNC_NOTIFY 標記的串流驅動程式可自由忽略應用程式傳送的 WatchPlugState。已設定 CAN_ASYNC_NOTIFY 的驅動程式會回應用戶端傳送的第一個 |WatchPlugState|，且不會回應後續的用戶端
|WatchPlugState| 呼叫直到外掛程式狀態與最近回報的內容改變為止。
串流目的和關聯
鈴聲緩衝區頻道
總覽
應用程式成功設定串流格式後，便會收到新的管道，代表與串流環形緩衝區的連線。用戶端會使用環形緩衝區管道建立共用記憶體緩衝區，然後開始/停止播放及擷取音訊串流資料。
環形緩衝區內容是由用戶端 (為了播放) 和驅動程式庫端 (用於錄製) 產生。因此，用戶端是播放的生產端，而錄製用的取用端，驅動程式庫則是錄製的生產端，而取用端的取用端。環形緩衝區內容可能直接由音訊硬體使用或產生，也可能經過驅動程式庫對每個樣本進行的軟體處理程序。
環形緩衝區資料生產作業會從成功回應 Start 指令的時間點，按名目進行後續作業。請注意，環形緩衝區幾乎可以確定在記憶體匯流排和音訊硬體之間，有一些形式的 FIFO 緩衝區，導致系統在串流中提前 (在擷取的情況下) 讀取資料，或可能留存資料 (在擷取的情況下)。務必在開始作業之前，用戶端查詢這個緩衝區的大小，以便他們瞭解串流的名詞推論讀取/寫入位置要保持多久，才能避免音訊故障。另請注意，由於系統的共用緩衝區性質，且驅動程式可能直接從這個緩衝區進行指定行銷區域導向硬體，因此對於在未自動快取的架構上執行的用戶端而言，務必確保在將播放資料寫入緩衝區後正確寫入快取，或在讀取擷取資料前將其快取失效。如需環形緩衝區資料移轉的說明，請參閱 ring_buffer.fidl 中的 RingBufferProperties 中的 driver_transfer_bytes。
取得共用緩衝區
如要傳送或接收音訊，應用程式必須先建立共用記憶體緩衝區。方法是透過環形緩衝區管道傳送 CreateRingBuffer 要求。這項作業只能在環形緩衝區停止時執行。
例如，如果因為已建立緩衝區且已經啟動環形緩衝區，導致使用 CreateRingBuffer 建立的管道遭到驅動程式庫關閉，則不得停止環環緩衝區，或捨棄現有的共用記憶體。如果應用程式在環形緩衝區停止時已建立緩衝區後要求新的緩衝區，就必須將現有的緩衝區 ii 必須無效，舊緩衝區現已消失。
應用程式要求環形緩衝區時，必須指定兩個參數：min_frames 和 clock_recovery_notifications_per_ring。
min_frames
用戶端需要為環形緩衝區分配的音訊影格數量下限。驅動程式可能會放大這個緩衝區，以滿足硬體需求。用戶端必須使用傳回的 VMO 大小 (以位元組為單位) 來判斷環形緩衝區的實際大小。用戶端不得假設緩衝區的大小 (由驅動程式庫決定) 完全等於要求的大小。驅動程式必須確保環形緩衝區的大小是音訊影格的必要數量。
clock_recovery_notifications_per_ring
用戶端希望驅動程式庫在每個循環期間透過環形緩衝區傳送的位置更新通知數量 (非必要)，這類通知主要用於復原時鐘。驅動程式只能以回覆 WatchClockRecoveryPositionInfo 要求的形式傳送這些內容。驅動程式應嘗試在環狀路線中平均地放置通知；然而，用戶端不應仰賴完全統一的更新通知間距。
ring_buffer
如果要求成功，驅動程式庫必須傳回 VMO 處理常式。該處理常式必須允許應用程式使用 zx_vmar_map 將 VMO 對應至其位址空間，並在播放時於緩衝區中讀取/寫入資料，或是在擷取時直接讀取緩衝區中的資料。
num_frames
如果要求成功，驅動程式庫也會傳回在緩衝區中使用的實際音訊影格數。傳回的 VMO 大小 (由 zx_vmo_get_size() 回報) 不得大於這個影格數量 (轉換為位元組時)。這個數字可能大於用戶端的 min_frames 要求，但必須小於這個數字。
啟動及停止環形緩衝區
用戶端可能會使用 Start 和 Stop 指令，要求開始或停止環形緩衝區。如果嘗試啟動已經開始的串流，則必須視為失敗。如果嘗試停止已經停止的串流，應視為成功。使用 CreateRingBuffer 作業建立共用緩衝區後，才能停止或啟動環形緩衝區。
成功啟動串流後，驅動程式必須在回應的 start_time 欄位中提供最適當的預估時間，說明硬體開始傳輸或擷取串流的時間。這個時間戳記必須取自透過 zx_clock_get_monotonic() 系統呼叫公開的時鐘。除了環形緩衝區的 FIFO 深度屬性以外，此時間戳記可讓應用程式傳送或接收串流資料，而不需要驅動程式庫定期更新位置。除了串流管道提供的外板延遲時間預估值外，這個時間戳記可讓應用程式在多個串流中同步處理音訊資訊的呈現，甚至能同步處理多部裝置的音訊資訊 (前提是您使用外部時間同步處理通訊協定來同步處理同步裝置同類群組的monotonic時間軸)。
成功啟動串流後，驅動程式必須確保在開始回應將開始回應排入環形緩衝區管道之前，不會傳送位置通知。
成功停止串流後，驅動程式必須確保在停止回應排入佇列後，任何位置通知都不會排入環形緩衝區管道。
位置通知
如果用戶端在 CreateRingBuffer 作業中透過非零的 clock_recovery_notifications_per_ring 要求，驅動程式庫會定期傳送更新至用戶端，通知用戶端目前的實際工作環境或緩衝區中的消耗位置。這個位置會在回覆 WatchClockRecoveryPositionInfo 訊息時，在 RingBufferPositionInfo 結構的 position 欄位中以位元組表示。訊息也包含 timestamp 欄位，其中包含這個位元組位置有效的時間 (格式為 zx::time)。只有在 GetVmo 函式中指定 clock_recovery_notifications_per_ring 且傳回 GetVmo 函式後，才能傳送 WatchClockRecoveryPositionInfo 要求。請注意，這些位置通知會指出驅動程式庫在緩衝區中使用或產生資料的位置，而「不是」名詞播放或擷取位置 (有時稱為「寫入遊標」或「讀取遊標」)。使用者抵達的時間無法保證完全一致，不應用來影響時鐘復原。不過，對應組合 (timestamp、position) 本身的值 ARE 是用來復原音訊串流的時鐘。如果用戶端發現驅動程式庫已消耗超過環形緩衝區中的某個點，該用戶端已寫入播放資料，就不會定義音訊呈現。客戶應增加時鐘的前置時間，並且確保日後能夠在串流中保持在這個時間點。同樣地，擷取音訊的用戶端不應嘗試讀取到超過駕駛環最新位置通知所指出的環形緩衝區範圍之外。
驅動程式播放和擷取位置必須「一律」在成功的 Start 指令後，從環狀緩衝區位元組 0 開始。當環形緩衝區位置到達 VMO 的結尾 (如 zx_vmo_get_size(...) 所示) 時，環狀緩衝區位置會改回零。驅動程式無需使用或產生音訊影格的整合數量資料。如果用戶端的串流位置概念取決於位置通知，則應要求每個環形傳送足夠的通知數量 (至少 2 個)，並迅速地在未發生別名的情況下迅速處理。
時鐘復原與同步
收到 AUDIO_STREAM_CMD_GET_CLOCK_DOMAIN 訊息後，驅動程式庫必須回應包含該裝置的時鐘網域 ID。如果音訊裝置已鎖定在本機系統單音時鐘上，且並未公開可供微調速率的機制，則應該傳回值 0 來代表本機 CLOCK_MONOTONIC 網域。用戶端除了 AUDIO_RB_POSITION_NOTIFY 訊息之外，也可以使用這項資訊來簡化音訊裝置的時鐘復原程序。
錯誤通知
意外終止的用戶端
如果環形緩衝區控制管道的用戶端因任何原因關閉，駕駛必須立即關閉控制管道並關閉環形緩衝區，因此系統不會繼續發出或擷取音訊。雖然我們鼓勵駕駛人以流暢的方式進行靜音轉換，但必須確保音訊串流無聲，而非循環播放。靜音轉換程序完成後，與播放或擷取相關聯的資源可能會釋出並供驅動程式庫重複使用。
如此一來，如果播放用戶端意外終止，系統會關閉用戶端頻道，導致音訊播放停止，而非繼續循環播放。