如何在單個藍牙設備上集成語音和立體聲音樂功能

設想藍牙移動電話支持HV3包類型的另外一種情形。藍牙立體聲耳機套件中的藍牙基帶將接受進入的連接-微微網主設備需要一個時隙來發送HV3數據包，下一個時隙來接收HV3包，在主設備需要發送接下來的HV3包之前，下4個時隙以及帶寬將可用。然而，如果藍牙音樂播放器使用流靜音機制實現了AVRCP暫停/播放，藍牙立體聲耳機套件在管理同時發送數據(靜音)和SCO連接的ACL鏈路時將出現問題。

圖10：HV3 SCO數據包類型+流靜音的順序圖表。

圖11：移動電話上SCO Beep的順序圖表。

非理想實現導致的另外一個問題是按鍵動作的處理。當音樂在ACL鏈路上傳送時移動電話的任何按鍵動作都會發出嘟嘟聲響。這時，用戶的體驗很不爽。因為每當有按鍵按下，在藍牙立體聲耳機套件中將發出嗶音，這需要暫停音樂，切換到SCO連接，播放嗶聲，恢復播放音樂，當下一次按鍵按下時再次中斷。一種變通的方法是要求用戶禁止移動電話上的按鍵嗶聲提示音。這既不合理也是有代價的，它要求支持電話、文檔和用戶教育，因此是不可接受的。

有幾種配置需要藍牙立體聲耳機和藍牙單聲道耳機分別加以考慮。當藍牙立體聲和藍牙單聲道功能需要同時存在時，這些配置累加會導致藍牙立體聲耳機套件設計的復雜性迅速增加。

過去，移動電話提供商在做出產品選擇時，需要根據不同的移動電話使用情形證明其合理性。一個例子是選用HV1包類型可以獲得比HV3包類型更好的質量。類似地，藍牙音樂播放器提供商做出了在很少的使用情形下表現不錯的選擇-例如使用流靜音實現AVRCP暫停/播放。這種選擇帶來的局限性被證明在立體聲-單聲道共存的情況下代價是很高的。最近藍牙SIG下面成立的AV-HFP工作組有望幫助解決這個問題。

其它方面的挑戰

還有以下系統問題需要在藍牙立體聲耳機套件設計中加以解決。

1. 管理在切換期間單芯片方案中的MIPS需求。MIPS負載可能占用單芯片方案90%~95%的處理能力，因為大多數藍牙基帶針對成本進行了優化設計。必須小心處理這種峰值MIPS負載。

2. 管理切換時的抖動。盡管對于無線流傳輸來說抖動總是一個主要的挑戰，但在切換時將變得特別嚴重。加之峰值MIPS負載，這個問題特別難于解決。

3. 延時。延時需要盡可能小，這樣才可以給用戶近似于有線連接的體驗。這個問題有兩個方面：呼叫進入和通話結束后的音樂恢復。對于第一種情況，如果延時很長，可能不能及時接通電話，而對于后者，用戶可能會覺得在切換期間音樂丟失了。對于任何一種情況，用戶體驗都將受到影響。

總之，藍牙音樂和語音的共存要求帶來了技術和非技術兩方面的各種挑戰。不過令人欣慰的是，這些挑戰并非是不可解決的，因為這些挑戰主要與每個公司的實現選擇和缺乏一致的指導原則有關。這些挑戰已經得到業界的全面認識，并正在得到解決。通過像藍牙SIG這些組織的協調以及每個公司的努力，完全可能將應用前景轉變成技術和商業上的成功故事。