處理音頻數據的設備和方法
【專利摘要】本發(fā)明涉及處理音頻數據的設備和方法。該設備包括：音頻處理器，被配置為在通信設備和第二通信設備之間的音頻通信連接期間執(zhí)行音頻處理；存儲器，被配置為根據第一預定義音頻通信連接事件存儲至少第一音頻處理器喚醒調度；控制器，被配置為：根據第二預定義音頻通信連接事件，設置與所述第一音頻處理器喚醒調度類似的至少一個第二音頻處理器喚醒調度，以及響應于第一或第二預定義音頻通信連接事件中的至少一個的發(fā)生，根據第一音頻處理器喚醒調度或第二音頻處理器喚醒調度中的至少一個喚醒音頻處理器，其中音頻處理器還被配置為：在音頻處理完成之后進入睡眠模式，并且響應于從控制器接收到的喚醒信號，從睡眠模式進入處理模式。
【專利說明】
處理音頻數據的設備和方法
技術領域
[0001 ]本文所描述的實施例總體涉及處理音頻數據的設備和方法。
【背景技術】
[0002]移動電話通常用于它們的用戶之間的呼叫。這種呼叫涉及音頻處理，例如由某些音頻處理部件執(zhí)行的對音頻數據的編碼和解碼。通常，這種音頻處理部件具有足夠的計算能力，能夠在短時間間隔內執(zhí)行音頻處理，并且在這些間隔之間可以進入睡眠模式。在功耗方面，期望保持自睡眠模式的喚醒次數和長度盡可能低。
【附圖說明】
[0003]在附圖中，相似的參考標記在所有不同視圖中通常指代相同的部件。附圖未必按比例繪制，相反，重點一般放在說明本發(fā)明的原理上。在以下描述中，參考以下附圖描述各個方面，其中:
[0004]圖1示出通信系統(tǒng)。
[0005]圖2示出在圖1的通信系統(tǒng)中使用的示例性幀結構的幀。
[0006]圖3示出從VoLTE角度來看的移動終端架構的示例。
[0007]圖4不出設備。
[0008]圖5示出說明處理音頻數據方法的流程圖。
[0009]圖6示出將UL/TX音頻處理活動與DL/RX音頻處理活動對準的過程/處理。
[0010]圖7示出UL喚醒調度與DL喚醒調度的對準。
[0011]圖8和8A-8D示出在20ms DRX無線電配置情況下的RX-TX同步。
[0012]圖9和9A-9D示出在40ms DRX無線電配置情況下的RX-TX同步。
【具體實施方式】
[0013]以下詳細描述參考附圖，這些附圖通過說明的方式示出了本公開的可以實施本發(fā)明的具體細節(jié)和方面?？梢岳闷渌矫?，并且可以進行結構、邏輯和電氣的改變而不背離本發(fā)明的范圍。本公開的各個方面不必然互相排斥，正如本公開的一些方面可以與本公開的一個或更多其它方面結合從而形成新的方面。
[0014]圖1示出例如根據3GPP(第三代合作項目)的通信系統(tǒng)100。
[0015]通信系統(tǒng)100可以是蜂窩移動通信系統(tǒng)(在下文中也稱為蜂窩無線電通信網絡)，包括無線接入網絡(例如E-UTRAN，根據LTE(長期演進)或LTE-Advanced的演進型UMTS(通用移動通信系統(tǒng))地面無線接入網絡)101和核心網絡(例如EPC，根據LTE或LTE-Advanced的演進型分組核心)102。無線接入網絡101可以包括基站(例如基站收發(fā)臺、eNodeB、eNB、家用基站、家用eNodeB、根據LTE或LTE-Advanced的HeNB) 103。每個基站103可以為無線接入網絡101的一個或多個移動無線小區(qū)104提供無線覆蓋。換句話說:無線接入網絡101的基站103可以跨越不同類型的小區(qū)104(例如，根據LTE或LTE-Advanced的例如宏小區(qū)、毫微微小區(qū)、微微小區(qū)、小小區(qū)、開放小區(qū)、封閉用戶組小區(qū)、混合小區(qū))。應該注意，在下文中描述的示例也可以應用于除了LTE通信網絡之外的其它通信網絡，例如根據UMTS、GSM(全球移動通信系統(tǒng))、WIFI等的通信網絡。
[0016]位于移動無線小區(qū)104中的移動終端(例如，UE) 105經由在移動無線小區(qū)104中提供覆蓋(換句話說，操作)的基站103，可以與核心網絡102和其它移動終端105進行通信。換句話說，操作移動終端105所位于的移動無線小區(qū)104的基站103可以提供包括rocp(分組數據會聚協(xié)議)層、RLC(無線線路控制)層和MAC(介質訪問控制)層的E-UTRA用戶平面終端，并控制包括朝向移動終端105的RRC(無線資源控制)層的平面終端。除了其它典型的諸如揚聲器、麥克風和存儲器的部件之外，移動終端105還包括應用處理器111和調制解調器112。
[0017]可以基于多址方法，經由空中接口106，在基站103與位于由基站103操作的移動無線小區(qū)104中的移動終端105之間傳輸控制數據和用戶數據?？梢栽谝苿油ㄐ艠藴士罩薪涌?例如，LTE空中接口 106)上部署不同的雙工方法，例如FDD(頻分雙工)或TDD(時分雙工)。
[0018]基站103通過第一接口 107(例如，X2接口)彼此互連?；?03還通過第二接口 108(例如，SI接口)連接到核心網絡102，例如經由S1-MME接口 108連接到MME(移動管理實體)并且通過Sl-U接口 108連接到服務網關(S-GW)ll(LSl接口 108支持MME/S-GW 109、110與基站103之間的多對多關系，即基站103可以連接到不止一個MME/S-GW 109、110，并且11^/3-6￥109、110可以連接到不止一個基站103。這可以使得能夠在LTE中實現網絡共享。
[0019]例如，MME 109可以負責控制位于E-UTRAN覆蓋區(qū)域中的移動終端的移動性，而S-Gff 110可以負責處理移動終端105與核心網絡102之間的用戶數據的傳輸。
[0020]在例如LTE的移動通信標準的情況下，無線接入網絡101(即，在LTE情況下的E-UTRAN)可以看成由基站103(即，在LTE情況下的eNB 103)組成，從而提供E-UTRA用戶平面(roCP/RLC/MAC)和朝向UE 105的控制平面(RRC)的協(xié)議終端。
[0021]通信系統(tǒng)100的每個基站103可以控制在其地理覆蓋區(qū)域(即由六邊形理想表示的移動無線小區(qū)104)內的通信。當移動終端105位于移動無線小區(qū)104內并預占(camp on)移動無線小區(qū)104(換句話說，向分配給移動無線小區(qū)104的跟蹤區(qū)域(TA)注冊)時，它與控制移動無線小區(qū)104的基站103進行通信。當呼叫由移動終端105的用戶發(fā)起(源于移動的呼口H)或者呼叫被定址到移動終端105 (止于移動的呼叫)時，在移動終端105與控制移動臺所位于的移動無線小區(qū)104的基站103之間建立無線信道。如果移動終端105移動離開建立呼叫的原始移動無線小區(qū)104并且建立在原始移動無線小區(qū)104中的無線信道的信號強度減弱，則通信系統(tǒng)可以發(fā)起呼叫轉移至移動終端105移動到的另一個移動無線小區(qū)104的無線信道。
[0022]使用移動終端105到E-UTRAN101和核心網絡102的連接，移動終端105可以與位于其它網絡中的其它設備進行通信，例如互聯(lián)網中的服務器，以便例如根據FTP(文件傳輸協(xié)議)使用TCP(傳輸控制協(xié)議)連接下載數據。
[0023]根據(無線)幀結構，執(zhí)行在移動終端105和對應基站103(即，操作移動終端105所位于的無線小區(qū)的基站)之間的數據傳輸。圖2中示出了幀結構的示例。
[0024]圖2示出示例性幀結構的幀200。
[0025]幀200可以用于全雙工和半雙工FDD兩者。幀200長1ms并由編號從O至19的20個
0.5ms長的時隙201組成。子幀202被定義為兩個相繼的時隙201。在每個1ms間隔中，十個子幀202可用于下行鏈路傳輸或上行鏈路傳輸。然而，應該注意，根據其它無線接入技術，例如WIFI，幀可以具有不同于十的子幀數目，并且子幀可以包括不止兩個時隙。
[O O 2 6 ]上行鏈路傳輸和下行鏈路傳輸在頻域中分開。根據時隙格式，子幀2 O 2可以分別在DL(下行鏈路)中和UL(上行鏈路)中包括12或140FDM(正交頻分多址)符號和12或14SC-FDMA符號。
[0027]移動終端105的用戶可以經由VoIP(基于IP的語音，例如在本示例中是VoLTE(基于LTE的語音))與另一個移動終端105的用戶進行通信。
[0028]圖3示出從VoLTE角度來看的移動終端300(例如，對應于移動終端105)的架構的示例。
[0029]關于音頻的發(fā)送，移動終端300包括音頻源301，例如移動終端300的用戶對著講話的麥克風連同音頻抽樣電路。音頻數據，例如音頻采樣(例如，PCM(脈沖編碼調制)采樣)被存儲在音頻輸入緩沖器302中。VoIP引擎303從音頻輸入緩沖器302中讀出音頻數據，并且通過例如根據編碼解碼器304對音頻數進行編碼并根據傳輸協(xié)議(例如，根據RTP(實時傳輸協(xié)議))生成分組，從而為傳輸準備這些數據。VoIP引擎303將處理后的音頻數據(例如，RTP分組)提供到移動終端300的收發(fā)器306，收發(fā)器306將處理后的音頻數據發(fā)送到無線接入網絡，例如發(fā)送到服務移動終端300的基站103。
[0030]關于音頻數據的接收，收發(fā)器306接收音頻數據，例如已編碼且為分組(例如，RTP分組)形式的音頻數據，并且將它們供給到VoIP引擎303 JoIP引擎303通過例如從分組中提取音頻數據并對其解碼，從而提取音頻數據，并且將所提取的音頻數據存儲在音頻輸出緩沖器303中，待由移動終端300的音頻輸出電路308(例如，包括數模轉換器和揚聲器)輸出。
[0031]在下文中，描述了一種通信設備，其例如通過將關于圖3所描述的音頻通信中的發(fā)送和接收活動對齊/對準，以此允許減小移動終端300的功耗。
[0032]圖4示出設備400。
[0033]設備400包括:音頻處理器401，被配置為在第一通信設備(例如，對應于設備400或包括設備400)和第二通信設備之間的音頻通信連接期間執(zhí)行音頻處理；以及存儲器402，被配置為根據第一預定義音頻通信連接事件，存儲至少第一音頻處理器喚醒調度。
[0034]此外，通信設備400包括控制器403，其被配置為基于(例如，根據)第二預定義音頻通信連接事件，設置與(例如，將與)第一音頻處理器喚醒調度類似的至少一個第二音頻處理器喚醒調度，并且響應于第一或第二預定義音頻通信連接事件中的至少一個，基于(例如，根據)第一音頻處理器喚醒調度或第二音頻處理器喚醒調度中的至少一個，將喚醒信號發(fā)送到音頻處理器以喚醒音頻處理器。
[0035]音頻處理器401還被配置為在音頻處理完成之后進入睡眠模式(或空閑模式)，并且響應于喚醒信號，從睡眠模式進入處理模式。
[0036]換句話說，通信設備(例如，對應于移動電話300)的部件(例如，應用處理器或調制解調器)的、針對音頻通信中的不同事件(以及例如，任務)的喚醒調度被對齊了。
[0037]例如，通過使得能夠動態(tài)地對齊音頻發(fā)送(TX)活動和接收(RX)活動，可以減小VoLTE功耗(或一般來說，任何VoIP呼叫功耗)。這可以例如包括以下項中的一個或多個:
[0038]減少用于執(zhí)行VoLTE(或VoIP)通信(S卩，呼叫)的喚醒次數。
[0039]可以在呼叫期間(例如，在呼叫期間的任何時間點處)執(zhí)行音頻TX/RX活動的對齊。例如，不必然在呼叫啟動時或切換時執(zhí)行。
[0040]音頻TX/RX活動的對齊可以以平穩(wěn)/平滑的方式發(fā)生。例如，在靜音時段期間執(zhí)行對齊，或者使用時間縮放執(zhí)行對齊，例如通過在上行鏈路(UL)中使用話音幀時間縮放來將上行鏈路傳輸活動與下行鏈路接收活動對齊。
[0041 ] 為了最小化對整體端到端延遲和話音質量的影響，對于VoLTE，例如UL/TX音頻活動與DL/RX音頻活動對齊，而不是反過來(使得該對齊過程不改變DL抖動緩沖管理處理和關聯(lián)活動，統(tǒng)計及觸發(fā))。這意味著例如，用于UL/TX音頻活動的觸發(fā)跟蹤用于DL/RX音頻活動的觸發(fā)。換句話說，例如，從哪個活動定義其它活動被調整(例如，偏移)到的調度來說，下行鏈路為主(鏈路)，上行鏈路為從(鏈路)。
[0042]音頻發(fā)送(S卩，上行鏈路)活動可以理解為包括UL/TX音頻處理活動，即上行鏈路中的音頻處理，例如編碼和分組生成，和UL/TX音頻無線傳輸活動，即上行鏈路無線發(fā)送，例如包括星座映射和經由空中接口的實際RF(無線頻率)發(fā)送。
[0043]類似地，音頻接收(即，下行鏈路)活動可以理解為包括DL/RX音頻處理活動，即下行鏈路中的音頻處理，例如從分組中的數據提取和解碼，和DL/RX音頻無線傳輸活動，即無線接收，例如包括經由空中接口的實際RF(無線頻率)接收和星座解映射。
[0044]通信設備的部件(例如，音頻處理器、存儲器和控制器)可以例如由一個或多個電路實施?！半娐贰笨梢岳斫鉃槿魏晤愋偷倪壿媽崿F實體，其可以是專用電路或執(zhí)行存儲在存儲器中的軟件、固件或其任何組合的處理器。因此“電路”可以是硬接線的邏輯電路或可編程邏輯電路，例如可編程處理器，例如微處理器。“電路”也可以是執(zhí)行軟件的處理器，例如任何類型的計算機程序。以下將更詳細描述的各個功能的任何其它類型的實施方式也可以理解為“電路”。
[0045]通信設備400例如執(zhí)行如圖5所示的方法。
[0046]圖5示出流程圖500。
[0047]流程圖500示出用于處理音頻數據的方法，該方法例如由通信設備執(zhí)行。
[0048]在501中，通信設備基于(例如，根據)第一預定義音頻通信連接事件，存儲至少第一音頻處理器喚醒調度。
[0049]在502中，通信設備基于(例如，根據)第二預定義音頻通信連接事件，設置與第一音頻處理器喚醒調度類似的至少一個第二音頻處理器喚醒調度。
[0050]在503中，響應于第一或第二預定義音頻通信連接事件中的至少一個，基于(例如，根據)第一音頻處理器喚醒調度或第二音頻處理器喚醒調度中的至少一個，通信設備發(fā)送喚醒信號以喚醒音頻處理器，從而在第一通信設備與第二通信設備之間的音頻通信連接期間執(zhí)行音頻處理。音頻處理器在音頻處理完成之后進入睡眠模式，并且響應于接收到喚醒信號而從睡眠模式進入處理模式。以下示例涉及進一步的實施例。
[0051]示例I是如圖4所示的設備。
[0052]在示例2中，示例I的主題可以可選地包括，第一預定義音頻通信連接事件是對要被發(fā)送到第二通信設備的音頻數據的處理的開始，并且第二預定義音頻通信連接是對從第二通信設備接收到的音頻數據的處理的開始。
[0053]在示例3中，示例2的主題可以可選地包括，音頻處理器被配置為與對要被發(fā)送到第二通信設備的音頻數據的處理相比，以更短的時間執(zhí)行對從第二通信設備接收到的音頻數據的處理，并且設置與第一音頻處理器喚醒調度類似的至少一個第二音頻處理器喚醒調度包括，將對從第二通信設備接收到的音頻數據的處理調度為，在對要被發(fā)送到第二通信設備的音頻數據的處理期間由應用處理器執(zhí)行。
[0054]在示例4中，示例1-3中任一項的主題可以可選地包括，第一預定義音頻通信連接事件是音頻數據至第二通信設備的無線發(fā)送，并且第二預定義音頻通信連接是對要被發(fā)送到第二通信設備的音頻數據的處理的開始。
[0055]在示例5中，示例1-4中任一項的主題可以可選地包括，第一預定義音頻通信連接事件是音頻數據自第二通信設備的無線接收，并且第二預定義音頻通信連接是對從第二通信設備接收到的音頻數據的處理的開始。
[0056]在示例6中，示例1-5中任一項的主題可以可選地包括，音頻處理是對要被發(fā)送到第二通信設備的音頻數據的音頻處理，并且包括對來自音頻源的音頻數據進行編碼和形成已編碼音頻數據的分組中的至少一個。
[0057]在示例7中，示例1-6中任一項的主題可以可選地包括，音頻處理是對從第二通信設備接收到的音頻數據的音頻處理，并且包括從已編碼的音頻數據的分組提取已編碼的音頻數據和對已編碼的音頻數據進行解碼中的至少一個。
[0058]在示例8中，示例1-7中任一項的主題可以可選地包括，設置與第一音頻處理器喚醒調度類似的至少一個第二音頻處理器喚醒調度包括，將基于至少一個第二音頻處理器喚醒調度的喚醒設置在第一音頻處理器喚醒調度的預定容差內。
[0059]在示例9中，示例8的主題可以可選地包括，預定容差是相鄰的基于第一音頻處理器喚醒調度的喚醒之間的時間的2 %、5 %、1 %或15 %。
[0060]在示例10中，示例1-9中任一項的主題可以可選地包括，作為音頻處理是對語音呼叫數據的處理。
[0061]在示例11中，示例1-10中任一項的主題可以可選地包括，音頻通信連接是基于IP的語音的音頻通信連接。
[0062]在示例12中，示例1-11中任一項的主題可以可選地包括，音頻通信連接是基于LTE的語音的音頻通信連接。
[0063]在示例13中，示例1-12中任一項的主題可以可選地包括，設置與第一音頻處理器喚醒調度類似的至少一個第二音頻處理器喚醒調度包括，將至少一個第二音頻處理器喚醒調度從之前在音頻通信連接期間音頻處理器被喚醒所依據的位置偏移到與第一音頻處理器喚醒調度類似的位置。
[0064]在示例14中，示例13的主題可以可選地包括，控制器被配置為在音頻通信連接期間搜索靜音時段，并且在找到的靜音時段期間執(zhí)行偏移。
[0065]在示例15中，示例13-14中任一項的主題可以可選地包括，控制器被配置為通過縮放或丟棄音頻數據執(zhí)行偏移。
[0066]在示例16中，示例1-15中任一項的主題可以可選地包括，控制器被配置為確定至少一個第二音頻處理器喚醒調度的喚醒定時與第一音頻處理器的喚醒定時之間的差值，并且設置與第一音頻處理器喚醒調度類似的至少一個第二音頻處理器喚醒調度包括，偏移至少一個第二音頻處理器喚醒調度，以減小至少一個第二音頻處理器喚醒調度的喚醒定時與第一音頻處理器喚醒調度的喚醒定時之間的差值。
[0067]在示例17中，示例16的主題可以可選地包括，控制器被配置為在音頻通信連接期間確定該差值。
[0068]在示例18中，示例16-17中任一項的主題可以可選地包括，控制器被配置為檢測該差值是否大于預定閾值，并且如果該差值大于預定閾值，則偏移至少一個第二音頻處理器喚醒調度以減小至少一個第二音頻處理器喚醒調度的喚醒定時與第一音頻處理器喚醒調度的喚醒定時之間的差值。
[0069]在示例19中，示例18的主題可以可選地包括，預定閾值是相鄰的基于第一音頻處理器喚醒調度的喚醒之間的時間的2 %、5 %、1 %或15 %。
[0070]在示例20中，示例1-19中任一項的主題可以可選地包括，音頻處理器是由第一通信設備的應用處理器或第一通信設備的調制解調器實現的。
[0071]在示例21中，示例1-20中任一項的主題可以可選地包括，第一通信設備是移動通信設備。
[0072]示例22是如圖5所示的處理音頻數據的方法。
[0073]在示例23中，示例22的主題可以可選地包括，第一預定義音頻通信連接事件是對要被發(fā)送到第二通信設備的音頻數據的處理的開始，并且第二預定義音頻通信連接是對從第二通信設備接收到的音頻數據的處理的開始。
[0074]在示例24中，示例23的主題可以可選地包括，與對要被發(fā)送到第二通信設備的音頻數據的處理相比，音頻處理器以更短時間執(zhí)行對從第二通信設備接收到的音頻數據的處理，并且設置與第一音頻處理器喚醒調度類似的至少一個第二音頻處理器喚醒調度包括，將對從第二通信設備接收到的音頻數據的處理調度為，在對要被發(fā)送到第二通信設備的音頻數據的處理期間由應用處理器執(zhí)行。
[0075]在示例25中，示例24的主題可以可選地包括，第一預定義音頻通信連接事件是音頻數據至第二通信設備的無線發(fā)送，并且第二預定義音頻通信連接是對要被發(fā)送到第二通信設備的音頻數據的處理的開始。
[0076]在示例26中，示例22-25中任一項的主題可以可選地包括，第一預定義音頻通信連接事件是音頻數據自第二通信設備的無線接收，并且第二預定義音頻通信連接是對從第二通信設備接收到的音頻數據的處理的開始。
[0077]在示例27中，示例22-26中任一項的主題可以可選地包括，音頻處理是對要被發(fā)送到第二通信設備的音頻數據的音頻處理，并且包括對來自音頻源的音頻數據進行編碼和形成已編碼音頻數據的分組中的至少一個。
[0078]在示例28中，示例22-27中任一項的主題可以可選地包括，音頻處理是對從第二通信設備接收到的音頻數據的音頻處理，并且包括從已編碼音頻數據的分組提取已編碼音頻數據和對已編碼音頻數據進行解碼中的至少一個。
[0079]在示例29中，示例22-28中任一項的主題可以可選地包括，設置與第一音頻處理器喚醒調度類似的至少一個第二音頻處理器喚醒調度包括，將基于至少一個第二音頻處理器喚醒調度的喚醒設置在第一音頻處理器喚醒調度的預定容差內。
[0080]在示例30中，示例29的主題可以可選地包括，預定容差是相鄰的基于第一音頻處理器喚醒調度的喚醒之間的時間的2 %、5 %、1 %或15 %。
[0081]在示例31中，示例22-30中任一項的主題可以可選地包括，音頻處理是對語音呼叫數據的處理。
[0082]在示例32中，示例22-31中任一項的主題可以可選地包括，音頻通信連接是基于IP的語音的音頻通信連接。
[0083]在示例33中，示例22-32中任一項的主題可以可選地包括，音頻通信連接是基于LTE的語音的音頻通信連接。
[0084]在示例34中，示例22-23中任一項的主題可以可選地包括，設置與第一音頻處理器喚醒調度類似的至少一個第二音頻處理器喚醒調度包括，將至少一個第二音頻處理器喚醒調度從之前在音頻通信連接期間音頻處理器被喚醒所依據的位置偏移到與第一音頻處理器喚醒調度類似的位置。
[0085]在示例35中，示例34的主題可以可選地包括，在音頻通信連接期間搜索靜音時段，并且在找到的靜音時段期間執(zhí)行偏移。
[0086]在示例36中，示例34-35中任一項的主題可以可選地包括，通過縮放或丟棄音頻數據執(zhí)行偏移。
[0087]在示例37中，示例22-36中任一項的主題可以可選地包括，確定至少一個第二音頻處理器喚醒調度的喚醒定時與第一音頻處理器喚醒調度的喚醒定時之間的差值，并且設置與第一音頻處理器喚醒調度類似的至少一個第二音頻處理器喚醒調度包括，偏移至少一個第二音頻處理器喚醒調度，以減小至少一個第二音頻處理器喚醒調度的喚醒定時與第一音頻處理器喚醒調度的喚醒定時之間的差值。
[0088]在示例38中，示例37的主題可以可選地包括，在音頻通信連接期間確定該差值。
[0089]在示例39中，示例37-38中任一項的主題可以可選地包括，檢測該差值是否大于預定閾值，并且如果該差值大于預定閾值，則偏移至少一個第二音頻處理器喚醒調度，以減小至少一個第二音頻處理器喚醒調度的喚醒定時與第一音頻處理器喚醒調度的喚醒定時之間的差值。
[0090]在示例40中，示例39的主題可以可選地包括，預定閾值是相鄰的基于第一音頻處理器喚醒調度的喚醒之間的時間的2 %、5 %、1 %或15 %。
[0091]在示例41中，示例22-40中任一項的主題可以可選地包括，音頻處理器是由第一通信設備的應用處理器或第一通信設備的調制解調器實現的。
[0092]在示例42中，示例22-41中任一項的主題可以可選地包括，第一通信設備是移動通信設備。
[0093]示例43是一種用于在移動通信設備中對應用處理器功耗和應用處理器處理延遲、調制解調器功耗和調制解調器處理延遲進行折中(trade-off)的方法，使得從全局上來說，在平臺層次上，對音頻應用處理器上行鏈路和下行鏈路活動相對無線調制解調器發(fā)送和接收活動的最優(yōu)且自適應的調度能夠用于根據預定義的、可配置的或兩者均有的策略，就功耗和延遲方面優(yōu)化性能，而不會在調度變更期間產生音頻偽聲(artifact)。
[0094]在示例44中，示例43的主題可以可選地包括，對齊上行鏈路活動和下行鏈路活動，以減小功耗。
[0095]示例45是計算機可讀介質，在其上記錄有指令，當指令由處理器執(zhí)行時使處理器根據示例22-44中任一項所述的用于處理音頻數據的方法。
[0096]示例46是一種設備，包括:音頻處理裝置，用于在第一通信設備與第二通信設備之間的音頻通信連接期間執(zhí)行音頻處理;存儲器，用于基于第一預定義音頻通信連接事件，存儲至少第一音頻處理裝置喚醒調度;控制裝置，用于根據第二預定義音頻通信連接事件，設置與第一音頻處理裝置喚醒調度類似的至少一個第二音頻處理裝置喚醒調度，并且響應于第一或第二預定義音頻通信連接事件中的至少一個，基于第一音頻處理裝置喚醒調度或第二音頻處理裝置喚醒調度中的至少一個，將喚醒信號發(fā)送到音頻處理裝置，以便喚醒音頻處理裝置;其中音頻處理裝置進一步在音頻處理完成之后進入睡眠模式，并且響應于接收到的喚醒信號而從睡眠模式進入處理模式。
[0097]在示例47中，示例46的主題可以可選地包括，第一預定義音頻通信連接事件是對要被發(fā)送到第二通信設備的音頻數據的處理的開始，并且第二預定義音頻通信連接是對從第二通信設備接收到的音頻數據的處理的開始。
[0098]在示例48中，示例47的主題可以可選地包括，音頻處理裝置用于與對要被發(fā)送到第二通信設備的音頻數據的處理相比，以更短的時間執(zhí)行對從第二通信設備接收到的音頻數據的處理，并且設置與第一音頻處理裝置喚醒調度類似的至少一個第二音頻處理裝置喚醒調度包括，將對從第二通信設備接收到的音頻數據的處理調度為，在對要被發(fā)送到第二通信設備的音頻數據的處理期間由應用處理器執(zhí)行。
[0099]在示例49中，示例46-48中任一項的主題可以可選地包括，第一預定義音頻通信連接事件是音頻數據至第二通信設備的無線發(fā)送，并且第二預定義音頻通信連接是對要被發(fā)送到第二通信設備的音頻數據的處理的開始。
[0100]在示例50中，示例46-49中任一項的主題可以可選地包括，第一預定義音頻通信連接事件是音頻數據自第二通信設備的無線接收，并且第二預定義音頻通信連接是對從第二通信設備接收到的音頻數據的處理的開始。
[0101]在示例51中，示例46-50中任一項的主題可以可選地包括，音頻處理是對要被發(fā)送到第二通信設備的音頻數據的音頻處理，并且包括對來自音頻源的音頻數據進行編碼和形成已編碼音頻數據的分組中的至少一個。
[0102]在示例52中，示例46-51中任一項的主題可以可選地包括，音頻處理是對從第二通信設備接收到的音頻數據的音頻處理，并且包括從已編碼音頻數據的分組提取已編碼音頻數據和對已編碼音頻數據進行解碼中的至少一個。
[0103]在示例53中，示例46-52中任一項的主題可以可選地包括，設置與第一音頻處理裝置喚醒調度類似的至少一個第二音頻處理裝置喚醒調度包括，將基于至少一個第二音頻處理裝置喚醒調度的喚醒設置在第一音頻處理裝置喚醒調度的預定容差內。
[0104]在示例54中，示例53的主題可以可選地包括，預定容差是相鄰的基于第一音頻處理裝置喚醒調度的喚醒之間的時間的2 %、5 %、1 %或15 %。
[0105]在示例55中，示例46-54中任一項的主題可以可選地包括，音頻處理是對語音呼叫數據的處理。
[0106]在示例56中，示例46-55中任一項的主題可以可選地包括，音頻通信連接是基于IP的語音的音頻通信連接。
[0107]在示例57中，示例46-56中任一項的主題可以可選地包括，音頻通信連接是基于LTE的語音的音頻通信連接。
[0108]在示例58中，示例46-57中任一項的主題可以可選地包括，設置與第一音頻處理裝置喚醒調度類似的至少一個第二處理裝置喚醒調度包括，將至少一個第二音頻處理裝置喚醒調度從之前在音頻通信連接期間音頻處理裝置被喚醒所依據的位置偏移到與第一音頻處理裝置喚醒調度類似的位置。
[0109]在示例59中，示例58的主題可以可選地包括，控制裝置用于在音頻通信連接期間搜索靜音時段，并且在找到的靜音時段期間執(zhí)行偏移。
[0110]在示例60中，示例58-59中任一項的主題可以可選地包括，控制裝置用于通過縮放或丟棄音頻數據執(zhí)行偏移。
[0111]在示例61中，示例46-60中任一項的主題可以可選地包括，控制裝置用于確定至少一個第二音頻處理裝置喚醒調度的喚醒定時與第一音頻處理裝置喚醒調度的喚醒定時之間的差值，并且設置與第一音頻處理裝置喚醒調度類似的至少一個第二音頻處理裝置喚醒調度包括，偏移至少一個音頻處理裝置喚醒調度，以減小至少一個第二處理裝置喚醒調度的喚醒定時與第一音頻處理裝置喚醒調度的喚醒定時之間的差值。
[0112]在示例62中，示例61的主題可以可選地包括，控制裝置用于在音頻通信連接期間確定該差值。
[0113]在示例63中，示例61-62中任一項的主題可以可選地包括，控制裝置用于檢測該差值是否大于預定閾值，并且如果該差值大于預定閾值，則偏移至少一個第二音頻處理裝置喚醒調度，以減小至少一個第二音頻處理裝置喚醒調度的喚醒定時與第一音頻處理裝置喚醒調度的喚醒定時之間的差值。
[0114]在示例64中，示例63的主題可以可選地包括，預定閾值是相鄰的基于第一音頻處理裝置喚醒調度的喚醒之間的時間的2 %、5 %、1 %或15 %。
[0115]在示例65中，示例46-64中任一項的主題可以可選地包括，音頻處理裝置是由第一通信設備的應用處理器或第一通信設備的調制解調器實現的。
[0116]在示例66中，示例46-65中任一項的主題可以可選地包括，第一通信設備是移動通信設備。
[0117]應該注意，以上任何示例的一個或多個特征可以與任何一個其它示例相結合。
[0118]在下文中，參考上面關于圖3所描述的結構更詳細地描述實施例。
[0119]應該注意，VoIP引擎303可以例如通過移動終端300的應用處理器111和通過移動終端300的調制解調器112來實現，調制解調器112例如也(至少部分地)實現收發(fā)器306。
[0120]可以預期的是，可以用VoIP引擎位于應用處理器111上(S卩，由應用處理器111實現)的架構，來實現通過關于圖4所描述的音頻通信活動的對齊，在功耗方面得到的最大改塞口 ο
[0121]其原因在于，借助VoIP303引擎在調制解調器112上的架構，即使減少了與音頻VoLTE處理活動有關的喚醒次數，調制解調器112也仍然可以被頻繁地激活，因為它并行執(zhí)行其它頻發(fā)的活動(例如，鄰小區(qū)監(jiān)測、尋呼請求監(jiān)測等)。特別地，例如，調制解調器112的MAC層必須每Ims執(zhí)行LTE處理。為了解決這個問題，音頻(上行鏈路/下行鏈路)處理活動可以與無線發(fā)送和無線接收活動對齊。因此，可以實現調制解調器喚醒次數被減少。這在下文中進一步更詳細地解釋。
[0122]在以下描述的示例中，假設VoIP引擎303由移動終端的應用處理器111實現，例如以應用處理器111執(zhí)行的應用的形式實現，并且音頻上行鏈路處理和音頻下行鏈路處理被對齊。
[0123]在VoIP引擎303位于應用處理器側上并且音頻上行鏈路和下行鏈路處理被對齊的情況下，一旦在典型的VoIP使用情況下(不包括例如視頻并行的并發(fā)情形)針對話音幀已經執(zhí)行了VoIP音頻處理活動，應用處理器111(以及例如移動終端的300SoC(片上系統(tǒng)))就可以接著進入低功耗模式，等待下一個將要處理的話音幀。所以，借助音頻上行鏈路處理和音頻下行鏈路處理的對齊，在VoLTE呼叫期間，將典型地每20ms或40ms發(fā)生一次應用處理器側上的喚醒，而在不用這種方法的情況下，每20ms或40ms兩次喚醒將是必需的(例如，取決于網絡DRX(不連續(xù)接收)/SPS(半永久調度)/ptime配置)。
[0124]代替使用隨機時間點進行UL/TX音頻和DL/TX音頻活動的對齊，在例如如下的一個示例中，執(zhí)行對齊以能夠實現低功耗，且對端到端延遲影響低(以及潛在地，不存在任何影響)。事實上，例如，通常相對/矛盾的兩個事物，即功耗和延遲，被優(yōu)化。
[0125]首先，控制器403測量UL/TX音頻活動和DL/TX音頻活動之間的未對齊。它可以例如收集統(tǒng)計數據以確定未對齊是否穩(wěn)定或移動:在VoIP情形下，由于網絡抖動和在接收側上使用基于采樣的抖動緩沖管理，DL/RX音頻活動的時刻可能是移動的。控制器403例如避免干擾這個事情，因為JBM(抖動緩沖管理)正在工作以最小化DL延遲同時使得能夠進行保護免受網絡抖動。所以，控制器403例如不偏移DL/RX活動，而是將UL音頻活動與DL音頻活動對齊。
[0126]在VoLTE系統(tǒng)中，對于VoLTE呼叫，可以使用兩種類型的調度:
[0127]I)動態(tài)調度:當移動終端(S卩，在LTE情況下是UE)具有要發(fā)送的數據時，UE將調度請求發(fā)送到網絡(例如，發(fā)送到E-UTRAN 101)以獲取準許用于UL無線發(fā)送的資源。所以，借助動態(tài)調度，UL無線發(fā)送的時刻可以經由該機制來改變。
[0128]2)半永久調度(SPS):在這種情況下，由網絡(例如，E-UTRANlOI)為UL發(fā)送分配預定義的時刻。這允許避免在每個話音幀處，針對授予UE用于無線發(fā)送的資源使用協(xié)商機制。在這種情況下，UE不能改變用于UL無線發(fā)送的無線UL時刻。
[0129]對于動態(tài)調度，UL音頻TX處理活動的偏移對端到端延遲具有有限的影響(大多數時間甚至沒有影響)，而在SPS端到端延遲的情況下，通常將被改變。
[0130]關于SPS，出現兩種情況:
[0131 ] UL音頻處理活動的偏移減小整體端到端延遲，或
[0132]UL音頻處理活動的偏移增加整體端到端延遲。
[0133]通過測量UL/TX音頻處理活動的完成和無線UL發(fā)送的開始之間逝去的時間，控制器403可以推斷出UL/TX音頻處理活動偏移將增加還是降低整體端到端延遲。
[0134]所以，基于該信息，控制器403可以采取有把握(educated)的決策，該決策可能使得:
[0135]1.減小功耗并且減小端到端延遲，
[0136]2.減小功耗并且對端到端延遲具有有限的影響或無影響，
[0137]3.減小功耗但增加端到端延遲，
[0138]其中通過偏移UL/TX音頻處理活動，使其與DL/RX音頻處理活動對齊，使得對于UL/TX音頻處理和DL/RX音頻處理存在單個喚醒源，或者換句話說，共同喚醒調度，以此實現功率減小。這可以借助VoIP引擎位于應用處理器上，即與調制解調器活動去相關，以此允許顯著減小功耗。
[0139]在情況I和2中，控制器403可以例如一直執(zhí)行偏移/對齊。在情況3中，控制器403可以基于設備策略決定是否執(zhí)行偏移/對齊。
[0140]控制器403可以在整個呼叫持續(xù)時間期間，動態(tài)且自適應地對齊VoIP呼叫期間的UL/TX音頻處理活動，其中以平滑的方式(不會產生可聽見的失真)執(zhí)行音頻處理活動的偏移，并且其中考慮到通常是相對/矛盾的兩個音頻KPK關鍵性能指標)，功耗和端到端延遲。
[0141]因此，為了低功耗和低延遲，在本示例中由應用處理器111實現的整個音頻系統(tǒng)在喚醒方面被動態(tài)調整。
[0142]例如，基于IMS(互聯(lián)網協(xié)議多媒體子系統(tǒng))APE(應用處理器)中心架構的移動終端可以關于功耗被優(yōu)化。
[0143]HS APE中心架構通常非常具有吸引力，因為它們能夠容易地支持IMS特征(IR.94，基于WiFi的IMS，RCSe等…)，能夠容易地升級，并且與VoIP引擎位于調制解調器上的調制解調器中心架構相比，更易于以成本有效的方式支持。調制解調器中心架構通常是針對一種使用情況(即，在LTE情況下是低功耗VoLTE呼叫)優(yōu)化的，但是與頂S APE中心架構相比，通常使得對其它MS使用情況和特征的支持變得更加復雜。
[0144]盡管如此，一些移動電話廠商正在推薦調制解調器中心架構，而其它廠商正在支持(并且在內部推進)APE中心架構。所以，可能期望的是，具有一種方法用于兩種架構。
[0145]應該注意，在VoLTE背景中描述的示例可以適于其它VoIP應用?，F今，在VoIP功耗方面最大的壓力是在VoLTE呼叫的背景中。
[0146]圖6示出UL/TX音頻處理活動與DL/RX音頻處理活動的對齊的處理。
[0147]該過程例如由通信設備400的控制器403執(zhí)行，通信設備400例如對應于移動終端105和移動終端300。
[0148]第一圖示601示出下行鏈路喚醒的下行鏈路喚醒調度，下行鏈路喚醒以20ms的時間間隔均勻隔開。此外，上行鏈路喚醒的上行鏈路喚醒調度包括上行鏈路喚醒603，上行鏈路喚醒603也以20ms的時間間隔均勻隔開。然而，可以看到，上行鏈路喚醒調度被向左偏移I Ims，即每個上行鏈路603比下行鏈路喚醒602提前I Ims。
[0149]控制器403例如在滑動窗口上測量該未對齊，即上行鏈路喚醒調度相對于下行鏈路喚醒調度的偏移。例如，控制器403可以進行測量持續(xù)一段預定時間，或者等待直到偏移在整個滑動窗口上穩(wěn)定。
[0150]換句話說，控制器403收集關于音頻UL喚醒和音頻DL喚醒未對齊的測量。由于DLSJBM(基于采樣的抖動緩沖管理)活動，DL喚醒可能是移動的，使得在對齊的情況下可以看至Ij，UL喚醒跟蹤DL喚醒。
[0151]所以，在考慮將UL音頻處理活動與DL音頻處理活動對齊之前，控制器403可以等待一段時間，直到DL喚醒穩(wěn)定。一旦DL喚醒調度穩(wěn)定，例如滿足穩(wěn)定標準，控制器403就基于測量結果(以及例如DL喚醒統(tǒng)計)來確定用于對齊的值。在本示例中，控制器403確定對齊值ALIGN=Ilms0
[0152]控制器403可以評估對端到端延遲的影響:
[0153]在VoLTE動態(tài)調度的情況下，控制器403可以被配置為執(zhí)行將UL喚醒調度偏移所確定的值。
[0154]在VoLTE半永久調度的情況下，控制器403可以被配置為評估對VoLTE連接的延遲的影響，即確定當UL喚醒調度被偏移所確定的值時，連接延遲是增加、降低，還是保持不變?；诶缈膳渲玫牟呗裕刂破?03接著決定是否執(zhí)行UL音頻處理活動的偏移。
[0155]應該注意，可能不需要精確對齊:由于多核架構現在是移動電話應用處理器的典型特征，DL處理活動配合在UL處理活動內，使得它們能夠在不同核(物理線程或超線程)上并行執(zhí)行，通常就足夠了。另外，VoLTE的UL處理活動比DL處理活動花費更多時間:這是使用像AMR(自適應多速率)或EVS(增強的語音服務)、0pus等編碼解碼器的結果，其中編碼比解碼耗費更多時間。事實上，AMR編碼通?；ㄙM約四倍AMR解碼的時間。
[0156]假設控制器403決定執(zhí)行對齊，則它偏移UL喚醒調度，使包括偏移的UL喚醒604在內的UL喚醒調度與DL喚醒調度的DL喚醒602對齊，如在第二圖示605中所示。因此，UL處理活動與DL處理活動對齊或重疊。
[0157]控制器403可以在VoLTE (或一般地說，Vo IP)呼叫期間執(zhí)行多次這種對齊。這可以在不產生音頻偽聲的情況下實現，使得UL處理活動可以平穩(wěn)地跟上DL處理活動的演進，并且整個音頻系統(tǒng)是動態(tài)的。
[0158]圖7示出控制器403可以如何執(zhí)行(S卩，實現)UL喚醒調度與DL喚醒調度的對齊。
[0159]在對齊之前，如第一圖示701所示，假設移動終端的音頻輸入緩沖器702(例如，對應于音頻輸入緩沖器302)被對應于22ms的音頻采樣填充，對應于22ms的音頻采樣如音頻輸入緩沖器702的區(qū)段703所示，該區(qū)段703在左側(假設緩沖器702是從右到左填充的)由指針cp_ptr劃界并且在右側由指針dsp_ptr劃界，指針cp_ptr指示從緩沖器702讀取新采樣，指針dsp_ptr指示VoIP引擎303的部件(例如，DSP(數字信號處理器)704)將采樣寫入到緩沖器702，以(例如，在由DSP 704進行某些處理之前)由編解碼器705(在讀取采樣之后)進行編碼。DSP 704和編解碼器705可以例如至少部分地實現VoIP引擎303。應該注意，在上行鏈路中，DSP 704向緩沖器702寫入并且應用處理器從緩沖器702中讀取，而在下行鏈路中，應用處理器向緩沖器寫入并且DSP 704從緩沖器702中讀取。
[0160]在默認情況下，在VoLTE呼叫期間的音頻UL處理活動的喚醒通常每20ms (或40ms)發(fā)生。理論上，網絡配置使用較高的值(20ms的倍數)是可能的，但是20ms和40ms是針對VoLTE呼叫的典型值。在其它編解碼器例如opus、ilbc或isac的情況下，可以使用不同值:5ms、1ms、30ms ο
[0161]當執(zhí)行音頻UL處理活動的偏移時，控制器403可以使用以下兩種方法中的一種:
[0162]丟棄音頻(例如，pcm(脈沖編碼調制))采樣?？刂破?03可以例如在靜音時段期間觸發(fā)該動作。
[0163]對音頻進行時間縮放，即音頻信號(例如，一個或多個話音幀)的壓縮或擴展。
[0164]控制器403也可以使用這兩種方法的組合。例如，它可以等待一靜音時段并且在沒有出現靜音時段的情況下，例如在一定超時之后，它可以觸發(fā)話音幀時間縮放。然而，在話音呼叫期間，在統(tǒng)計學上存在接近50%的靜音時段，并且即使當用戶連續(xù)講話時，也存在定期的小靜音時段。
[0165]對于對齊來說，在本示例中，需要少于20ms的靜音時段，所以在靜音時段期間丟棄音頻采樣可以被預期為是合適的，允許覆蓋多數(如果不是所有)的情況。在極端情況下，為了允許處理所有情形，控制器可以將話音幀時間縮放視為附加的改善(ref inement)。
[0166]在圖7的示例中，一旦控制器403已經決定偏移音頻UL處理活動，并且一旦它已經確定了指明UL音頻處理活動應當被偏移多少ms的對齊值(ALIGN= 11ms)，控制器403就每20ms(或每40ms)執(zhí)行對捕獲的采樣的(例如，pcm)分析，以檢測適合于采樣丟棄但不產生可聽見的音頻偽聲的幀。
[0167]當控制器403已經檢測到這種幀時，控制器403例如通過讀取并丟掉一些音頻采樣或，如圖7所示，通過倒回(rewind)計數器或指針，使得忽略要被丟棄的音頻采樣并且隨后將被改寫，以此丟棄與對齊值(即，在本示例中是Ilms的樣本)給定的ms那樣多的音頻采樣。
[0168]具體地，在圖7的示例中，指針cp_ptr被倒回(向右偏移Hlms，如第二圖示706所示，使得等效地丟棄了 Ilms的音頻采樣，另外Ilms的音頻采樣必須輸入到緩沖器中，直到喚醒被觸發(fā)。例如，如果在22ms的緩沖水平下觸發(fā)了喚醒，則在倒回計數器cp_ptr之后，Ilms仍然丟失，并且僅在另一個I Ims之后，用于對完整的話音幀進行UL編碼的丟失采樣是可用的并且UL喚醒被觸發(fā)，使得音頻UL處理活動和關聯(lián)的UL喚醒被延遲I Ims。
[0169]在偏移之后，UL喚醒調度再次繼續(xù)周期性喚醒，每20ms(或40ms)，使得音頻UL處理活動與音頻DL處理活動的對齊已經被執(zhí)行。
[0170]控制器403在整個呼叫期間可以再三地重復該過程。因此，音頻系統(tǒng)在VoLTE/VoIP呼叫期間是動態(tài)的，其中DL(回放)為主，UL以自適應且平滑的方式執(zhí)行與DL的定期對齊。它是針對低功耗優(yōu)化的，并且能夠應對致力于達到最小下行鏈路延遲和最大網絡抖動保護的系統(tǒng)，而在大多數情況下不對UL延遲產生影響，并且在其余情況下能夠采取一些折中決策(功率對UL延遲)。
[0171]上面關于圖6和圖7描述的示例基于VoIP引擎303實現在應用處理器111上的架構。然而，類似的方法也可以用于VoIP引擎303實現在調制解調器(例如，LTE調制解調器112)上的架構中。
[0172]在下文中，描述了基于調制解調器中心架構的示例，S卩VoIP引擎303實現在調制解調器112上，其中考慮了在上行鏈路無線傳輸和下行鏈路無線傳輸方面被優(yōu)化了的網絡設置和沒有被優(yōu)化的網絡設置兩者的情況。
[0173]在以下示例中，為了減小在呼叫(例如，IMS或IR92呼叫)期間的VoLTE平臺(例如，移動終端300)的整體功耗，核心喚醒(在本示例中是調制解調器喚醒)的次數被減少。為此目的，在呼叫期間所需的活動被同步和調度，以增加核心睡眠機會。
[0174]具體地，在本示例中，將上行鏈路音頻處理和音頻下行鏈路處理被對齊至上行鏈路無線(例如，LTE)傳輸和下行鏈路無線(例如，LTE)傳輸調度，如在圖8和圖9中所示。
[0175]圖8和圖9示出說明上行鏈路活動和下行鏈路活動的時間的時間圖800、900。
[0176]在圖800、900中，相應部件/功能的活動狀態(tài)由陰影格子指示，而部件/功能的非活動狀態(tài)由空白格子指示。
[0177]在圖8和圖9所示的示例中，UL和DL音頻處理被對齊至UL和DL無線傳輸。
[0178]在針對VoLTE呼叫優(yōu)化的網絡配置中，UL TX和DL RX LTE時隙彼此靠近(理想地，在四Attk時間傳輸間隔)內)，以便在與Tx相同的時隙中發(fā)送rx ack(確認)，或者反之亦然。SR(調度請求)的位置801、901靠近持續(xù)時間開始(011011作1:;[0115丨31'1:)。在小于DRX循環(huán)的SR周期的情況下，移動終端300選擇最靠近持續(xù)時間開始的SR。
[0179]利用與音頻處理(編碼/解碼(如果可用的話)、RTP組幀、IP組幀)有關的某個偏移和傳播時間，相對于TX傳輸804、904和RX傳輸805、905調度來自音頻子系統(tǒng)的、用于觸發(fā)音頻數據的發(fā)送或接收到的數據的播放的UL中斷802、902和DL中斷803、903。從調制解調器中心的角度并且還從AP中心的角度來看，這允許具有低延遲和功耗的配置。實際上，當由于音頻數據的接收而產生音頻播放的中斷時，應用處理器和調制解調器已經被喚醒，如調制解調器狀態(tài)806、906以及應用處理器狀態(tài)807、907所示。
[0180]在LTE無線接收和無線發(fā)送彼此不靠近的非優(yōu)化網絡配置的情況下，控制器403可以確定要減小功耗還是延遲。為了減小AP中心解決方案中的功耗，UL處理中斷和DL處理中斷可以被定位于同一喚醒循環(huán)/周期中。在無線電條件差的情況下，實際的成功的RX時隙會被偏移(即，實際的RX將由于網絡而更遲)?？刂破?03可以使用該信息來定位UL處理中斷和DL音頻處理中斷，以減小功耗和延遲兩者。
[0181]VoIP引擎303實現在LTE調制解調器112頂部的應用處理器上的架構的情況下，在減小應用處理器的功耗與減小調制解調器的功耗之間潛在地存在折中。
[0182]由于編解碼器編碼(例如，AMR編碼)通常比解碼長得多，因此對于與應用處理器上的上行鏈路編碼并行地調度應用處理器上的DL解碼，存在某些靈活性，而不需要兩次喚醒應用處理器。
[0183]例如，調制解調器112基于它對TX/RX無線傳輸時隙調度的了解向應用處理器報告，或者從調制解調器角度限制UL/DL活動的最優(yōu)偏移，以優(yōu)化調制解調器功耗。如果該偏移仍然使得應用處理器111上的DL處理能夠發(fā)生在UL處理結束之前，則控制器執(zhí)行該配置并可以因此實現應用處理器和調制解調器兩者的單次喚醒。
[0184]否則，控制器403可以做出決策，使得:
[0185]兩次喚醒應用處理器并且一次喚醒調制解調器，或
[0186]—次喚醒應用處理器并且兩次喚醒調制解調器。
[0187]在兩次喚醒的情況下，根據兩個活動之間的時間間隔(使得能夠有或多或少的睡眠時間)，調制解調器和應用處理器可以提供功耗影響評估，這使控制器能夠做出有把握的決策。
[0188]雖然已經描述了具體方面，但是本領域技術人員應該理解，可以進行各種形式和細節(jié)上的改變而不背離如由所附權利要求限定的本公開的各方面的精神和范圍。該范圍因此由所附權利要求指示并且因此意圖涵蓋落在權利要求等效物的含義和范圍內的所有改變。
【主權項】
1.一種設備，包括: 音頻處理器，被配置為在第一通信設備和第二通信設備之間的音頻通信連接期間執(zhí)行音頻處理； 存儲器，被配置為根據第一預定義音頻通信連接事件存儲至少第一音頻處理器喚醒調度； 控制器，被配置為: 基于第二預定義音頻通信連接事件，設置與所述第一音頻處理器喚醒調度類似的至少一個第二音頻處理器喚醒調度，以及 響應于所述第一預定義音頻通信連接事件或所述第二預定義音頻通信連接事件中的至少一個，基于所述第一音頻處理器喚醒調度或所述第二音頻處理器喚醒調度中的至少一個，將喚醒信號發(fā)送到所述音頻處理器，以喚醒所述音頻處理器； 其中，所述音頻處理器還被配置為:在音頻處理完成之后進入睡眠模式，并且響應于所述喚醒信號，從所述睡眠模式進入處理模式。2.根據權利要求1所述的設備，其中，所述第一預定義音頻通信連接事件是對要被發(fā)送到所述第二通信設備的音頻數據的處理的開始，并且所述第二預定義音頻通信連接是對從所述第二通信設備接收到的音頻數據的處理的開始。3.根據權利要求2所述的設備，其中，所述音頻處理器被配置為:與要被發(fā)送到所述第二通信設備的音頻數據的處理相比，以更短的時間執(zhí)行對從所述第二通信設備接收到的音頻數據的處理，并且其中，設置與所述第一音頻處理器喚醒調度類似的所述至少一個第二音頻處理器喚醒調度包括，將對從所述第二通信設備接收到的音頻數據的處理調度為，在對要被發(fā)送到所述第二通信設備的音頻數據的處理期間由所述應用處理器執(zhí)行。4.根據權利要求1所述的設備，其中，所述第一預定義音頻通信連接事件是音頻數據至所述第二通信設備的無線發(fā)送，并且所述第二預定義音頻通信連接是對要被發(fā)送到所述第二通信設備的音頻數據的處理的開始。5.根據權利要求1所述的設備，其中，所述第一預定義音頻通信連接事件是音頻數據自所述第二通信設備的無線接收，并且所述第二預定義音頻通信連接是對從所述第二通信設備接收到的音頻數據的處理的開始。6.根據權利要求1所述的設備，其中，所述音頻處理是對要被發(fā)送到所述第二通信設備的音頻數據的音頻處理，并且包括對來自音頻源的音頻數據進行編碼和形成已編碼音頻數據的分組中的至少一個。7.根據權利要求1所述的設備，其中，所述音頻處理是對從所述第二通信設備接收到的音頻數據的音頻處理，并且包括從已編碼音頻數據的分組中提取已編碼音頻數據和對已編碼音頻數據進行解碼中的至少一個。8.根據權利要求1所述的設備，其中，設置與所述第一音頻處理器喚醒調度類似的所述至少一個第二音頻處理器喚醒調度包括，將基于所述至少一個第二音頻處理器喚醒調度的喚醒設置在所述第一音頻處理器喚醒調度的預定容差內。9.根據權利要求8所述的設備，其中，所述預定容差是相鄰的基于所述第一音頻處理器喚醒調度的喚醒之間的時間的2 %、5 %、1 %或15 %。10.根據權利要求1所述的設備，其中，所述音頻處理是對語音呼叫數據的處理。11.根據權利要求1所述的設備，其中，所述音頻通信連接是基于IP的語音的音頻通信連接。12.根據權利要求1所述的設備，其中，所述音頻通信連接是基于LTE的語音的音頻通信連接。13.根據權利要求1所述的設備，其中，設置與所述第一音頻處理器喚醒調度類似的所述至少一個第二音頻處理器喚醒調度包括，將所述至少一個第二音頻處理器喚醒調度從之前在音頻通信連接期間所述音頻處理器被喚醒所依據的位置偏移到與所述第一音頻處理器喚醒調度類似的位置。14.根據權利要求13所述的設備，其中，所述控制器被配置為:在所述音頻通信連接期間搜索靜音時段，并且在找到的靜音時段期間執(zhí)行所述偏移。15.根據權利要求13所述的設備，其中，所述控制器被配置為:通過縮放或丟棄音頻數據來執(zhí)行所述偏移。16.根據權利要求1所述的設備，其中，所述控制器被配置為:確定所述至少一個第二音頻處理器喚醒調度的喚醒定時與所述第一音頻處理器喚醒調度的喚醒定時之間的差值，并且其中，設置與所述第一音頻處理器喚醒調度類似的所述至少一個第二音頻處理器喚醒調度包括，偏移所述至少一個第二音頻處理器喚醒調度，以減小所述至少一個第二音頻處理器喚醒調度的喚醒定時與所述第一音頻處理器喚醒調度的喚醒定時之間的所述差值。17.根據權利要求16所述的設備，其中，所述控制器被配置為:在所述音頻通信連接期間確定所述差值。18.根據權利要求16所述的設備，其中，所述控制器被配置為檢測所述差值是否大于預定閾值，并且如果所述差值大于所述預定閾值，則偏移所述至少一個第二音頻處理器喚醒調度，以減小所述至少一個第二音頻處理器喚醒調度的喚醒定時與所述第一音頻處理器喚醒調度的喚醒定時之間的所述差值。19.根據權利要求18所述的設備，其中，所述預定閾值是相鄰的基于所述第一音頻處理器喚醒調度的喚醒之間的時間的2 %、5 %、1 %或15 %。20.根據權利要求1所述的設備，其中，所述音頻處理器是由所述第一通信設備的應用處理器或所述第一通信設備的調制解調器實現的。21.根據權利要求1所述的設備，其中，所述第一通信設備是移動通信設備。22.—種用于處理音頻數據的方法，包括: 基于第一預定義音頻通信連接事件，存儲至少第一音頻處理器喚醒調度； 基于第二預定義音頻通信連接事件，設置與所述第一音頻處理器喚醒調度類似的至少一個第二音頻處理器喚醒調度； 響應于所述第一預定義音頻通信連接事件或所述第二預定義音頻通信連接事件中的至少一個，基于所述第一音頻處理器喚醒調度或所述第二音頻處理器喚醒調度中的至少一個，將喚醒信號發(fā)送到音頻處理器，以喚醒所述音頻處理器并且在第一通信設備和第二通信設備之間的音頻通信連接期間執(zhí)行音頻處理； 其中，所述音頻處理器在音頻處理完成之后進入睡眠模式，并且響應于接收到所述喚醒信號而從所述睡眠模式進入處理模式。23.—種用于在移動通信設備中對應用處理器功耗和應用處理器處理延遲、調制解調器功耗和調制解調器處理延遲進行折中的方法，使得從全局上來說，在平臺層次上，對音頻應用處理器上行鏈路和下行鏈路活動相對無線調制解調器發(fā)送和接收活動的最優(yōu)且自適應的調度能夠用于根據預定義的、可配置的或兩者均有的策略，在功耗和延遲方面優(yōu)化性能，而不會在調度變更期間產生音頻偽聲。24.根據權利要求23所述的方法，包括對齊上行鏈路活動和下行鏈路活動，以便減小功耗。25.一種計算機可讀介質，在其上記錄有指令，所述指令當由處理器執(zhí)行時使所述處理器執(zhí)行根據權利要求22至24中任一項所述的方法。
【文檔編號】H04W52/02GK106028369SQ201610108403
【公開日】2016年10月12日
【申請日】2016年2月26日
【發(fā)明人】P·溫格特納, J·帕龍
【申請人】英特爾公司