發布日期：2022-07-14 點擊率：60
可以說沒有人懷疑藍牙音樂的前途一片光明。在2005年的第一季度,幾乎所有的頂級手機提供商都推出或啟動支持音樂的移動電話-諾基亞在4月推出了N91型號的手機,索尼-愛立信在3月的CeBit上發布了隨身聽(Walkman)手機,在同一展會上,三星公司發布了SGHi300,而摩托羅拉公司的iTune版移動電話也成為媒體的頭條。
但是,還存在另一個必須面對的事實,即藍牙立體聲耳機的普及要落后于移動音樂的發展速度,從而使得上述的好消息打了折扣。其原因并不難理解。隨著藍牙已成為短距離手機無線傳輸的事實標準,而且單聲道藍牙耳機已日益普及,用戶并不希望使用兩套藍牙音頻設備-一套用于通話,而另外一套用于立體聲(音樂播放器)。
藍牙音頻耳機設備分類
關于藍牙音頻設備,定義上可以分為如下三種:
1.藍牙單聲道(語音)耳機:這種耳機出貨已經有一段時間了,成熟度已經很高。藍牙單聲道耳機是一種小型的藍牙設備,用戶可以用它進行免提通話。
2.藍牙立體聲耳機:這類耳機只允許使用者欣賞立體聲音樂。
3.藍牙立體聲耳機套件:該在套件允許使用者在欣賞立體聲音樂的同時進行免提通話。狀態切換涉及到在立體聲耳機中將音樂流媒體狀態平滑地切換到語音通話狀態,并且在通話結束后再切換回音樂流狀態。
圖1:分散網絡的實例。
圖2:微微網絡的實例
藍牙應用場景分類
與藍牙立體聲和藍牙語音相關的用戶應用情景有很多種,不過其中大多數可以歸納為以下兩種情形:
1. 音樂播放器-移動電話連接:某個用戶正在使用藍牙立體聲耳機聽音樂,這時移動電話有電話呼入。這時音樂將自動暫停,她可以在耳機中聽到電話鈴聲,然后接聽電話。掛斷電話后,音樂馬上從先前暫停的地方繼續播放。上述用戶情景大多數要求藍牙立體聲耳機成為兩個微微網中的公共設備。在其中一個網絡中,移動電話需要成為主設備,音樂播放器則是另外一個網絡中的從設備。藍牙立體聲耳機套件本身則成為其中一個微微網絡中的主設備,另外一個網絡中的從設備,從而形成一個分散式網絡。在某些情況下,可能不會形成分散網絡,此時藍牙立體聲耳機套件將成為主設備。
2. 多媒體電話連接:用戶正在利用支持音樂的最新藍牙移動電話欣賞無線音樂。這時他的話機上顯示有個電話呼入；話機音樂暫停,隨之藍牙立體聲耳機聲音停止。通過使用藍牙立體聲耳機上的“通話”按鈕進行通話。當通話一結束,音樂自動地從暫停的地方繼續播放。這種情景將創建有兩個設備的單個微微網絡。
用戶體驗所面臨的挑戰
表面上看起來這兩種應用都比較簡單--暫停音樂、接聽電話、通話結束后立即恢復音樂的播放。實際沒那么簡單。在藍牙耳機套件中集成語音和立體聲功能,同時提供簡單和直觀的用戶體驗充滿了挑戰。這些挑戰包括以下三類:
1. 技術挑戰:這些問題與藍牙規范相關,要么不足以解決這些問題,要么就是不夠明確。例如,當用于流媒體音樂的ACL鏈路已經存在時,是不可能建立HV1 SCO鏈路進行通話的。HV1數據包類型需要占用整個帶寬。
2. 實現挑戰:這些問題與規范的解釋以及隨后實現強制性或可選性功能有關。例如,很多移動電話每當有按鍵按下時都將建立一個SCO連接。為了在藍牙立體聲耳機中聽到話機上有鍵按下,耳機中的音樂每隔若干毫秒就需要暫停一下,這將產生一種令人沮喪的用戶體驗。
3. 指導原則的缺乏:因為某些時候規范并不充分或不夠清楚,而大量公司又迫不及待地在他們的產品中實現這些規范,因此業界急需藍牙語音和音樂共存的指導原則。直到最近,藍牙SIG和相關公司才意識到藍牙立體聲耳機應用所展示的巨大機會。多家藍牙組織已經開始去解決藍牙立體聲與語音功能的共存和互操作性問題。
問題并非在于技術本身
仔細分析上述應用中所遇到的種種挑戰,發現問題的核心并非在于技術本身。藍牙立體聲耳機套件是藍牙功能集成的中心。對于音樂播放器和移動電話連接而言,藍牙立體聲耳機套件是移動電話和音樂播放器之間的連接鏈路,對于多媒體電話連接,即使移動電話可能知道SCO和ACL兩個鏈路,在管理切換上藍牙立體聲耳機套件也扮演著關鍵的角色。
如前面討論的那樣,用戶體驗涉及到暫停音樂、在耳機上播放鈴聲,根據用戶的喜好接聽或不接聽,以及通話結束后恢復播放音樂。藍牙立體聲耳機單獨地處理暫停和恢復順序。類似地,藍牙單聲道耳機也能單獨地處理語音順序。挑戰在于將這些功能放在一起。
最初的音頻-視頻遙控協議(AVRCP)命令暫停(Pause)和播放(Play)的語言并不與高級音頻分配協議(A2DP)連接嚴格關聯。目前在系統中集成藍牙立體聲功能的音樂播放器在接收暫停命令時采用了下面三種選擇之一:1. 待機/啟動；2. 斷開/連接；3. 流靜音。
待機/啟動是AVRCP暫停和播放命令的理想實現方式,如圖3所顯示。然而在圖3中的A2DP待機/啟動是可選命令,在很多方案中并沒有實現。這導致了下面之一作為變通的情形。
圖3:使用A2DP待機/啟動的AVRCP暫停/播放實現。
斷開/連接是一種強制命令,不受可選的待機/啟動命令所面臨的問題影響。該選項顯示在圖4中。
圖4:使用A2DP斷開/連接的AVRCP暫停/播放實現
這種方式受兩個主要的缺陷影響。AVRCP暫停/播放語義不嚴格對應斷開/連接。它還因為重新連接的協議協商(所有編解碼參數重新協商)導致更高的延時,好像是一個新的連接一樣。
流靜音是另外一種方法,可以用于實現AVRCP暫停/播放語義。當藍牙立體聲耳機套件調用AVRCP暫停命令時,藍牙音樂播放可以開始流靜音,對用戶而言,音樂將表現為已經暫停。圖5中顯示了這個選項。
圖5:使用流靜音的AVRCP暫停/播放實現
事實上,這是AVRCP暫停/播放的模擬情形。這可能是一種可行的方案,當待機/啟動沒有實現,對于可以接受的用戶體驗來說,與斷開/連接相關的延時可能太長了。
值得注意的是,與實現AVRCP暫停/播放語義所采用的方法無關,最終用戶可能不會體驗到真正的暫停/播放行為,即音樂從它最初停止的地方恢復,除非藍牙AV子系統具有到音樂播放器的數字接口,以及用于控制音樂播放器狀態的節目接口。
通過上述所有這些分析可以得出以下的結論,即藍牙音樂播放器用于解決AVRCP暫停/播放語義的方法并不一致。缺乏一致認可的規則是導致藍牙立體聲耳機設計和實現復雜度增加的原因。
關鍵在于實現
除了上述的問題之外,移動電話方面的問題也是難題的一部分。在單聲道領域,移動電話提供商采用了簡單的方法來使語音質量達到最佳,并認為這樣是可行的。今天,全球有超過1億部移動電話支持藍牙。然而,這些移動電話在藍牙語音實現上千差萬別。例如,某些移動電話需要在呼叫進入時建立ACL+SCO連接,而某些要求ACL連接一直打開,只有在有電話呼入時才建立SCO連接；也有一些方案讓SCO連接始終打開。此外,不同電話供應商以及同一個供應商的不同型號的移動電話支持的SCO包類型(HV1、HV2、HV3)可能都不相同。如圖6所示。
圖6:已經得到解決并基于移動電話的藍牙通話情景。
圖7和圖8顯示了在呼叫進入時和ACL連接始終打開的ACL順序圖表。
圖7:呼叫進入時的ACL鏈路
圖8:ACL鏈路處于常開狀態
藍牙立體聲耳機套件設計師需要解決的音樂播放器和移動電話的真實配置主要源于音樂播放器和/或移動電話提供商的實現選擇。
考慮一個用A2DP待機/啟動實現AVRCP暫停/播放的例子,移動電話的ACL鏈路保持接通(呼叫進入時SCO連接),并且只支持HV1包。如果藍牙立體聲耳機套件的音樂流速度為350kbps,藍牙立體聲耳機套件中的藍牙基帶將拒絕任何HV1包類型的SCO連接請求。這是因為HV1包類型需要占用整個帶寬,HV1包是一種單時隙包類型,帶有10個信息字節,需要在每兩個時隙內傳遞；微微網主設備需要1個時隙來發送HV1包,另外一個時隙用于接收HV1包,因此完全占用了整個帶寬。在速度為350kbps(在理想的情形下,當呼叫進入時將最終進入到待機模式)的已有ACL連接中,藍牙立體聲耳機套件中的藍牙基帶知道不能滿足HV1包類型的并發SCO鏈接需求,因此會拒絕SCO連接請求。這對于只支持HV1包類型的移動電話來說,明顯是一個很大的問題。圖9顯示了HV1 SCO包類型連接+待機/啟動的順序圖表。
圖9:HV1 SCO包類型連接+待機/啟動的順序圖表。
設想藍牙移動電話支持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這些組織的協調以及每個公司的努力,完全可能將應用前景轉變成技術和商業上的成功故事。
作者:Yogesh Kamat Mhamai
高級軟件工程師
Bikash Chowdhury
無線立體聲項目經理
Impulsesoft
