我的一位同事在測試 GStreamer 的 alsasrc 與 osssrc 插件時發現，alsasrc 消耗了相當驚人的 CPU 資源（在我們使用的晶片上約占 16%）。他詢問我，為何晶片供應商提供的測試工具卻能維持極高的效率（約僅占 1~2%）。這巨大的效能差距引起了我的好奇，我決定深入研究原因。
經過數小時的調查，我發現當參數設定為「非阻塞模式 (non-blocking mode)」時，該插件可能會在 While 迴圈中導致忙碌等待 (busy wait)。我對程式碼進行了簡單修改並重新執行，結果 CPU 使用率降低到 12%。雖然略有改進，但我依然感到有些沮喪。
於是，我開始嘗試不同的參數組合，因為我同事發現了 alsasrc 與測試工具間的三個差異點：
alsasrc設定為「非阻塞模式」，而測試工具為「阻塞模式 (block mode)」。alsasrc的聲道設定為 1，而測試工具設定為 2。- 測試工具限制了緩衝區大小 (buffer size)，而
alsasrc沒有這項限制。
針對第一點：我原以為非阻塞模式應該更有效率，但關鍵在於必須改善其忙碌等待的機制。
針對第二點：這非常奇特，因為當我在 alsasrc 插件將聲道數設定為 2 時，CPU 使用率竟然大幅降低。這讓我開始懷疑這是否與 I2S 匯流排的特性有關。我在網路上搜尋，並未發現任何資料指明「當音訊匯流排為 I2S 時，必須在 GStreamer 的 alsasrc 插件中將聲道參數設為 2」。稍後我會進一步確認此現象。
針對第三點：我認為限制緩衝區大小以優化效能是合理的做法。
Comments & Feedback