一种分布式解码控制器、分布式解码方法及音频终端与流程

本发明涉及通信技术领域，更具体地说，涉及一种分布式解码控制器、分布式解码方法及音频终端。

背景技术：

在移动互联网时代，随着智能终端的推广和普及，用户不断追求高品质的音视体验，对多媒体的音质音效要求也越来越高，因此，高码率、多声道、无损音源渐渐成为各种音频终端的标配。

APE(Monkey's audio，无损压缩音乐格式)作为一种主流的无损压缩格式，压缩速率是动态的，压缩时只压缩可被压缩部分，不能被压缩的部分还是会保留下来。为了将音源体积变小，编码端采用的编码算法压缩比越高，解码越麻烦，终端内存占用率越高，耗电量自然越大。尤其是对于最高品质的APE，其压缩等级为Insane(疯狂)，APEInsane的压缩比是5000:1，市场上的终端往往都是单独通过硬件解码模块或者软件解码模块对APEInsane进行解码，就会导致解码不充分，所以播放时往往会出现一定的抖动，因此进一步导致播放效果不够饱满和流畅，甚至还会出现ANR(Application Not Responding，应用程序无响应)对话框，使用户不得不选择“等待”而让程序继续运行，或者选择“强制关闭”结束程序的运行，降低了用户体验的满意度。

技术实现要素：

本发明要解决的技术问题在于：现有终端单独通过硬件解码模块或软件解码模块中的一个对音频流中的音频帧进行解码，导致音频帧解码不充分，从而使终端无法正常播放音频文件的问题；针对该技术问题，提供一种分布式解码控制器、分布式解码方法及音频终端。

为解决上述技术问题，本发明提供一种分布式解码控制器，所述分布式解码控制器包括：

音频流获取模块，用于获取待解码的音频流；

分布式控制模块，用于按照预设的分布式解码分配原则，提取音频流中需要通过硬解码的音频帧以及需要通过软解码的音频帧分别发送至硬件解码模块和软件解码模块进行解码。

进一步地，分布式解码分配原则包括：交替循环的从待解码音频流的音频帧中，先依次提取N帧作为需要通过硬解码的音频帧后，再依次提取M帧作为需要通过软解码的音频帧；M取大于等于1的整数值。N取大于所述M的整数值。

其中，M的取值为1，N的取值为4,6或8。

进一步地，分布式解码控制器，还包括解码方式控制模块，用于在分布式控制模块按照分布式解码分配原则提取音频帧之前，判断待解码音频流中的音频帧的压缩比是否大于等于预设的高压缩比阈值，如是，通知分布式控制模块按照分布式解码分配原则提取音频帧；否则，将所述待解码音频流中的音频帧发送至所述硬件解码模块或所述软件解码模块进行解码。

其中，所述高压缩比阈值的取值范围为大于等于3000:1，小于等于5000:1。

本发明提供了一种音频终端，包括：

硬件解码模块、软件解码模块以及上述任一种分布式解码控制器，分布式解码控制器用于控制将待解码音频流中的音频帧发送至硬件解码模块和/或软件解码模块进行解码。

本发明还提供了一种分布式解码方法，包括：

获取待解码的音频流；

按照预设的分布式解码分配原则，提取音频流中需要通过硬解码的音频帧以及需要通过软解码的音频帧分别发送至硬件解码模块和软件解码模块进行解码。

进一步地，分布式解码分布原则包括：循环的从待解码音频流的音频帧中，依次提取N帧作为需要通过硬解码的音频帧后，再依次提取M帧作为需要通过软解码的音频帧；M取大于等于1的整数值。N取大于所述M的整数值。

进一步地，获取到待解码的音频流之后，按照分布式解码分配原则提取音频帧之前，还包括：判断待解码的音频流中音频帧的压缩比是否大于等于预设的高压缩比阈值，如是，按照分布式解码分配原则提取音频帧；否则，将音频流中的音频帧发送至硬件解码模块或软件解码模块进行解码。

其中，待解码音频流中的音频帧压缩格式为无损压缩音频格式。

有益效果

本发明所提出的分布式解码控制器、分布式解码方法及音频终端，通过获取待解码的音频流，按照预先设定的分布式解码分配原则，提取音频流中需要通过硬解码的音频帧以及需要通过软解码的音频帧分别发送至硬件解码模块和软件解码模块进行解码，使音频流中的音频帧能通过硬件解码模块和软件解码模块的协同合作完成解码，进一步地提升了音频播放的流畅度。尤其是对于高压缩比的音频帧，相对现有单独通过硬件解码模块或者软件解码模块中的一个进行解码，可以提升解码性能，尤其适用于无损等高压缩比的音频格式，从而丰富了用户的听觉体验，提升了用户体验的满意感

附图说明

下面将结合附图及实施例对本发明作进一步说明，附图中：

图1为实现本发明各个实施例一个可选的移动终端的硬件结构示意图；

图2为本发明实施例一中的分布式解码方法流程示意图一；

图3为本发明实施例一中的分布式解码方法流程示意图二；

图4为本发明实施例二中的分布式解码方法流程示意图；

图5为本发明实施例三中的分布式解码控制器结构示意图一；

图6为本发明实施例三中的分布式解码控制器结构示意图二；

图7为本发明实施例四中的分布式解码控制器在安卓系统中的结构框图；

图8为本发明实施例五中的音频终端的结构示意图。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明的说明，其本身并没有特定的意义。因此，"模块"与"部件"可以混合地使用。

本实施例中的音频终端可以以各种形式来实施。例如，可以包括诸如移动电话、智能电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。

图1为实现本发明各个实施例一个可选的移动终端的硬件结构示意图。

移动终端100可以包括无线通信单元110、A/V(音频/视频)输入单元120、用户输入单元130、感测单元140、输出单元150、存储器160、接口单元170、控制器180和电源单元190等等。图1示出了具有各种组件的移动终端，但是应理解的是，并不要求实施所有示出的组件，可以替代地实施更多或更少的组件，将在下面详细描述移动终端的元件。

无线通信单元110通常包括一个或多个组件，其允许移动终端100与无线通信系统或网络之间的无线电通信。例如，无线通信单元可以包括广播接收模块、移动通信模块、无线互联网模块、短程通信模块和位置信息模块中的至少一个，通过以上各通信模块对外实现对应的通信功能。

A/V输入单元120用于接收音频或视频信号。A/V输入单元120可以包括相机121，相机121对在视频捕获模式或图像捕获模式中由图像捕获装置获得的静态图片或视频的图像数据进行处理。处理后的图像帧可以显示在显示模块151上。经相机121处理后的图像帧可以存储在存储器160(或其它存储介质)中或者经由无线通信单元110进行发送，可以根据移动终端的构造提供两个或更多相机121。麦克风122可以在电话通话模式、记录模式、语音识别模式等等运行模式中经由麦克风接收声音(音频数据)，并且能够将这样的声音处理为音频数据。麦克风122可以实施各种类型的噪声消除(或抑制)算法以消除(或抑制)在接收和发送音频信号的过程中产生的噪声或者干扰。

用户输入单元130可以根据用户输入的命令生成键输入数据以控制移动终端的各种操作。用户输入单元130允许用户输入各种类型的信息，并且可以包括键盘、锅仔片、触摸板(例如，检测由于被接触而导致的电阻、压力、电容等等的变化的触敏组件)、滚轮、摇杆等等。特别地，当触摸板以层的形式叠加在显示模块151上时，可以形成触摸屏。

感测单元140检测移动终端100的当前状态，(例如，移动终端100的打开或关闭状态)、移动终端100的位置、用户对于移动终端100的接触(即，触摸输入)的有无、移动终端100的取向、移动终端100的加速或减速移动和方向等等，并且生成用于控制移动终端100的操作的命令或信号。例如，当移动终端100实施为滑动型移动电话时，感测单元140可以感测该滑动型电话是打开还是关闭。另外，感测单元140能够检测电源单元190是否提供电力或者接口单元170是否与外部装置耦接。感测单元140可以包括接近传感器141。

接口单元170用作至少一个外部装置与移动终端100连接可以通过的接口。例如，外部装置可以包括有线或无线头戴式耳机端口、外部电源(或电池充电器)端口、有线或无线数据端口、存储卡端口、用于连接具有识别模块的装置的端口、音频输入/输出(I/O)端口、视频I/O端口、耳机端口等等。识别模块可以是存储用于验证用户使用移动终端100的各种信息并且可以包括用户识别模块(UIM)、客户识别模块(SIM)、通用客户识别模块(USIM)等等。另外，具有识别模块的装置(下面称为"识别装置")可以采取智能卡的形式，因此，识别装置可以经由端口或其它连接装置与移动终端100连接。接口单元170可以用于接收来自外部装置的输入(例如，数据信息、电力等等)并且将接收到的输入传输到移动终端100内的一个或多个元件或者可以用于在移动终端和外部装置之间传输数据。

另外，当移动终端100与外部底座连接时，接口单元170可以用作允许通过其将电力从底座提供到移动终端100的路径或者可以用作允许从底座输入的各种命令信号通过其传输到移动终端的路径。从底座输入的各种命令信号或电力可以用作用于识别移动终端是否准确地安装在底座上的信号。输出单元150被构造为以视觉、音频和/或触觉方式提供输出信号(例如，音频信号、视频信号、警报信号、振动信号等等)。

输出单元150可以包括显示模块151、音频输出模块152、警报模块153等等。

显示模块151可以显示在移动终端100中处理的信息。例如，当移动终端100处于电话通话模式时，显示模块151可以显示与通话或其它通信(例如，文本消息收发、多媒体文件下载等等)相关的用户界面(UI)或图形用户界面(GUI)。当移动终端100处于视频通话模式或者图像捕获模式时，显示模块151可以显示捕获的图像和/或接收的图像、示出视频或图像以及相关功能的UI或GUI等等。

同时，当显示模块151和触摸板以层的形式彼此叠加以形成触摸屏时，显示模块151可以用作输入装置和输出装置。显示模块151可以包括液晶显示器(LCD)、薄膜晶体管LCD(TFT-LCD)、有机发光二极管(OLED)显示器、柔性显示器、三维(3D)显示器等等中的至少一种。这些显示器中的一些可以被构造为透明状以允许用户从外部观看，这可以称为透明显示器，典型的透明显示器可以例如为TOLED(透明有机发光二极管)显示器等等。根据特定想要的实施方式，移动终端100可以包括两个或更多显示模块(或其它显示装置)，例如，移动终端可以包括外部显示模块(未示出)和内部显示模块(未示出)。触摸屏可用于检测触摸输入压力以及触摸输入位置和触摸输入面积。

音频输出模块152可以在移动终端处于呼叫信号接收模式、通话模式、记录模式、语音识别模式、广播接收模式等等模式下时，将无线通信单元110接收的或者在存储器160中存储的音频数据转换音频信号并且输出为声音，音频输出模块152将音频数据转换为音频信号输出声音，可以是通过将音频数据解码后再输出声音，其中音频数据的解码可以通过移动终端100上的硬件解码模块和软件解码模块共同完成。而且，音频输出模块152可以提供与移动终端100执行的特定功能相关的音频输出(例如，呼叫信号接收声音、消息接收声音等等)，音频输出模块152可以包括扬声器、蜂鸣器、听筒等等。

警报模块153可以提供输出以将事件的发生通知给移动终端100。典型的事件可以包括呼叫接收、消息接收、键信号输入、触摸输入等等。除了音频或视频输出之外，警报模块153可以以不同的方式提供输出以通知事件的发生。例如，警报模块153可以以振动的形式提供输出，当接收到呼叫、消息或一些其它进入通信(incoming communication)时，警报模块153可以提供触觉输出(即，振动)以将其通知给用户。通过提供这样的触觉输出，即使在用户的移动电话处于用户的口袋中时，用户也能够识别出各种事件的发生。警报模块153也可以经由显示模块151或音频输出模块152提供通知事件的发生的输出。

存储器160可以存储由控制器180执行的处理和控制操作的软件程序等等，或者可以暂时地存储己经输出或将要输出的数据(例如，电话簿、消息、静态图像、视频等等)。而且，存储器160可以存储关于当触摸施加到触摸屏时输出的各种方式的振动和音频信号的数据。

存储器160可以包括至少一种类型的存储介质，所述存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等等。而且，移动终端100可以与通过网络连接执行存储器160的存储功能的网络存储装置协作。

控制器180通常控制移动终端的总体操作。例如，控制器180执行与语音通话、数据通信、视频通话等等相关的控制和处理。另外，控制器180可以包括用于再现(或回放)多媒体数据的多媒体模块181，多媒体模块181可以构造在控制器180内，或者可以构造为与控制器180分离。控制器180可以执行模式识别处理，以将在触摸屏上执行的手写输入或者图片绘制输入识别为字符或图像。

电源单元190在控制器180的控制下接收外部电力或内部电力并且提供操作各元件和组件所需的适当的电力。

这里描述的各种实施方式可以以使用例如计算机软件、硬件或其任何组合的计算机可读介质来实施。对于硬件实施，这里描述的实施方式可以通过使用特定用途集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理装置(DSPD)、可编程逻辑装置(PLD)、现场可编程门阵列(FPGA)、处理器、控制器、微控制器、微处理器、被设计为执行这里描述的功能的电子单元中的至少一种来实施，在一些情况下，这样的实施方式可以在控制器180中实施。对于软件实施，诸如过程或功能的实施方式可以与允许执行至少一种功能或操作的单独的软件模块来实施。软件代码可以由以任何适当的编程语言编写的软件应用程序(或程序)来实施，软件代码可以存储在存储器160中并且由控制器180执行。

基于上述移动终端硬件结构，提出本发明的分布式解码控制器、分布式解码方法及音频终端。

以下通过具体实施例进行详细说明。

第一实施例

参照图2所示，本实施例提供一种分布式解码方法，包括：

S101：获取待解码的音频流。

S102：按照预设的分布式解码分配原则，提取音频流中需要通过硬解码的音频帧以及需要通过软解码的音频帧分别发送至硬件解码模块和软件解码模块进行解码。

本实施例中的分布式解码分配原则包括：交替循环的从待解码音频流的音频帧中，先依次提取N帧作为需要通过硬解码的音频帧后，再依次提取M帧作为需要通过软解码的音频帧；M取大于等于1的任意整数值。N取大于M的任意整数值。此外，本实施例中的分布式解码分配原则还包括交替循环的从待解码音频流的音频帧中，先依次提取M帧作为需要通过软解码的音频帧后，再依次提取N帧作为需要通过硬解码的音频帧；M取大于等于1的任意整数值。N取大于M的任意整数值。

例如，可以交替循环的从待解码音频流的音频帧中依次提取6帧作为需要通过硬解码的音频帧后，再依次提取1帧作为需要通过软解码的音频帧，由于通常情况下，硬件模块对音频帧的解码能力往往优于软件模块对音频帧的解码能力，所以本实施例中N取大于M的整数值。但是在某些情况下，基于成本或者其他的应用场景的考虑，N也可以取小于等于M的整数值。

此外，需要说明的是，本实施例中，硬件解码模块和软件解码模块对提取的音频流中的音频帧进行解码可以同时进行，也可以分别进行。

例如，若本实施例中的分布式解码分配原则为：循环的从待解码音频流的音频帧中依次提取4帧作为需要通过硬解码的音频帧后，再依次提取1帧作为需要通过软解码的音频帧。硬件解码模块接收到4帧需要通过硬解码的音频帧后就对这4帧音频帧进行相应解码，而软件解码模块接收到根据分布式分配原则得到的1帧需要通过软解码的音频帧后，可以直接对这1帧音频帧进行相应解码，也可以待软件解码模块检测到硬件解码模块完成了硬解码之后，再对这1帧音频帧进行相应解码。

需要说明的是，当硬件解码模块和软件解码模块对提取的音频流中的音频帧进行的解码操作是同时进行时，通过硬件解码模块和软件解码模块解码的音频帧可以是带有时序的音频帧。

应当理解的是，本实施例中的硬件解码模块的功能可以通过DSP(Digital Signal Processing，数字信号处理)实现，实现硬件解码模块功能的软件代码可以构造于在DSP内，相应地，本实施例中软件解码模块的功能可以通过处理器或者控制器实现，实现软件解码模块功能的代码可以存储在存储器中并且由处理器或者控制器执行。

本实施例中，获取到待解码的音频流之后，按照分布式解码分配原则提取音频帧之前，还可以包括：

S103：判断待解码的音频流中音频帧的压缩比是否大于等于预设的高压缩比阈值。

S104：若判断得知待解码的音频流中音频帧的压缩比大于等于预设的高压缩比阈值，则按照分布式解码分配原则提取音频帧。

S105：若判断得知待解码的音频流中音频帧的压缩比小于预设的高压缩比阈值，则将音频流中的音频帧发送至硬件解码模块或软件解码模块进行相应解码。

具体的，可以参见图3所示，其中，高压缩比阈值的取值范围可以是大于等于3000:1，小于等于5000:1，例如，取高压缩比阈值为4000:1，也即当判断得知待解码的音频流中音频帧的压缩比大于等于4000:1时，按照分布式解码分配原则提取音频帧，将经提取得到的需要通过硬解码的音频帧以及需要通过软解码的音频帧分别发送至硬件解码模块和软件解码模块进行解码；当判断得知待解码的音频流中音频帧的压缩比小于4000:1时，直接将音频流中的音频帧发送至硬件解码模块或软件解码模块进行解码，此时，可以随机地将音频流中的音频帧发送给硬件解码模块或者软件解码模块的任意一个进行解码。或者，取高压缩比阈值为4500:1，当判断得知待解码的音频流中音频帧的压缩比大于等于4500:1时，按照分布式解码分配原则提取音频帧，将经提取得到的需要通过硬解码的音频帧以及需要通过软解码的音频帧分别发送至硬件解码模块和软件解码模块进行解码；当判断得知待解码的音频流中音频帧的压缩比小于4500:1时，直接将音频流中的音频帧发送至硬件解码模块或软件解码模块进行解码.

应当理解的是，本实施例中的高压缩比阈值开发人员可以根据具体的应用场景的要求具体设置。

此外需要说明的是，本实施例中的待解码音频流中的音频帧压缩格式可以为无损压缩音频格式，例如，可以是APE、FLAC(Free Lossless Audio Codec，无损音频压缩编码)或者ALAC(Apple Lossless Audio Codec，苹果的无损音频压缩编码格式)等等。

在提高音频播放多样性和流畅性的同时，为了降低产品的生产开发成本，还可以通过运用模块化的方式，使本实施例提供的分布式解码方法形成一套固定的流程，以此来提高生产力。

本实施例提供的分布式解码方法，通过获取待解码的音频流，然后按照预先设定的分布式解码分配原则，提取音频流中需要通过硬解码的音频帧以及需要通过软解码的音频帧分别发送至硬件解码模块和软件解码模块进行解码，硬件解码模块和软件解码模块对音频帧进行协同解码，从而能充分完成高压缩比的高复杂解码，从而充分发挥了终端的硬件解码模块和软件解码模块的解码能力，使得音频的播放效果更加流畅和饱满，丰富了用户的听觉体验，提升了用户体验的满意度。

第二实施例

为了使高压缩比的音频帧能充分完成解码，使音频的播放效果更流畅更饱满，本实施例进一步提供一种分布式解码方法，以待解码音频流中的音频帧压缩格式为APEInsane为例进行说明。

定义ApeInsaneDecoder(疯狂等级的无损压缩音乐格式解码器)模块，用于标记不同帧数的音频帧，分别输送至硬件解码模块和软件解码模块模块协同解码，以完成高压缩比的高复杂解码。

定义供Ape InsaneDecoder模块调用的接口。

APEInsane的压缩比为5000：1，单独使用硬件解码模块或软件解码模块往往无法充分及时对音频帧进行解码，会导致APP(Application，应用程序)无响应，播放不流畅。而且因为分别调用硬件解码模块和软件解码模块进行处理，会增加系统的内存和耗电开销，所以默认关闭解码Ape Insane格式，将开关“audio.insane.decoder.enable”(音频，疯狂，解码，使能)默认设置为0。

本实施例中，当需要对压缩格式为APEInsane的音频帧进行解码时，通过调用ApeInsaneDecoder模块的接口，访问ApeInsaneDecoder模块，将标记的不同帧数的音频帧分别输送至硬件解码模块和软件解码模块模块进行协同解码，以完成高压缩比的高复杂解码。其中，编写的ApeInsaneDecoder模块的软件代码可以如下：

设置ApeInsaneDecoder模块的开关，控制是否进行分布式解码。相应的软件代码可以如下：

audio.insane.decoder.enable 1 为1时进行解码，为0时不解码

在此需要说明的是，本实施例中PickAudioFrame解析标记不同个数的音频帧，分别输送至APE软、硬件解码模块，具体为交替循环地解析标记4帧输送至硬件解码模块，再依次解析标记1帧输送至软件解码模块。

本实施例中ApeInsaneDecoder模块的分布式解码方法参见图4所示，包括：

S301：读取系统属性audio.insane.decoder.enable。

S302：判断audio.insane.decoder.enable＝1是否成立，如是，转至S303，如否，转至S305。

S303：解析标记不同个数的音频帧，分别输送至APE软、硬件解码模块。

S304：APE软件解码模块对接收到的4n音频帧进行相应解码生成脉冲编码调制流。

S305：实验性功能解码器对接收到的音频帧进行相应解码。应当理解的是S305与S304可以同时进行，也可以分别进行。

S306：实验性功能渲染器进行渲染处理。

为了降低产品的生产开发成本，还可以通过运用模块化的方式，使本实施例提供的分布式解码方法形成一套固定的流程，以此来提高生产力。

具体的，可以通过配置Android.mk文件，设置LOCAL_MODULE(局部模块)＝ApeInsaneDecoder，引用变量include$(BUILD_SHARED_LIBRARY)；

根据配置属性，编译生成一个公用的动态库libapeInsaneDecoder.so供多个不同平台使用。

相应地，当要在系统中使用动态库libapeInsaneDecoder.so时：

在stagefright的audioparse模块引用头文件ApeInsaneDecoder.h；在音频解析解码框架stagefright模块配置的Android.mk文件引用LOCAL_SHARED_LIBRARIES+＝libapeInsaneDecoder；调用initApeDecoder()创建APE分布式解码器；再调用pickAudioFrame()解析标记不同类型的音频帧；分别调用transportToApeSoftDecoder()和transportToApeDspHwDecoder()进行相应的软解码和硬解码；最后调用release()释放销毁APE分布式解码器。

此外，需要说明的是，ApeInsaneDecoder模块在调试的时候可以通过adb端口设置ApeInsaneDecoder模块解码的开或关，具体代码可以如下：

adb shell setprop audio.insane.decoder.enable 1 开启分布式APE Insane解码；

adb shell setprop audio.insane.decoder.enable 0 关闭分布式APE Insane解码。

通过本实施例提供的分布式解码方法，可以完成高压缩比的高复杂解码，从而使高压缩比格式的音频文件也能进行流畅的播放，丰富了用户的听觉体验。

第三实施例

本实施例提供一种分布式解码控制器，具体参照图5所示，包括音频流获取模块41和分布式控制模块42，其中，音频流获取模块41用于获取待解码的音频流；分布式控制模块42用于按照预设的分布式解码分配原则，提取音频流中需要通过硬解码的音频帧以及需要通过软解码的音频帧分别发送至硬件解码模块和软件解码模块进行解码。

应当理解的是，本实施例音频流获取模块41获取到的待解码音频流中的音频帧压缩格式可以为无损压缩音频格式，例如，可以是APE、FLAC或者ALAC等等。

需要说明的是，本实施例中的分布式解码分配原则包括：交替循环的从待解码音频流的音频帧中，先依次提取N帧作为需要通过硬解码的音频帧后，再依次提取M帧作为需要通过软解码的音频帧；M取大于等于1的任意整数值。N取大于M的任意整数值。此外，本实施例中的分布式解码分配原则还包括交替循环的从待解码音频流的音频帧中，先依次提取M帧作为需要通过软解码的音频帧后，再依次提取N帧作为需要通过硬解码的音频帧；M取大于等于1的任意整数值。N取大于M的任意整数值。例如，M的取值可以为1，N的取值可以为4、6或者8等。由于通常情况下，硬件模块对音频帧的解码能力往往优于软件模块对音频帧的解码能力，所以本实施例中N取大于M的整数值。但是在某些情况下，基于成本或者其他的应用场景的考虑，N也可以取小于等于M的整数值。

此外，需要说明的是，本实施例中，硬件解码模块和软件解码模块对提取的音频流中的需要进行硬解码和软解码的音频帧所进行的解码操作，可以同时进行，也可以分别进行。

例如，若本实施例中的分布式解码分配原则为：交替循环的从待解码音频流的音频帧中依次提取6帧作为需要通过硬解码的音频帧后，再依次提取2帧作为需要通过软解码的音频帧。硬件解码模块接收到6帧需要通过硬解码的音频帧后就对这2帧音频帧进行相应解码，而软件解码模块接收到根据分布式分配原则得到的2帧需要通过软解码的音频帧后，可以直接对这2帧音频帧进行相应解码，也可以待软件解码模块检测到硬件解码模块完成了硬解码之后，再对这2帧音频帧进行相应解码。

本实施例中，当硬件解码模块和软件解码模块对提取的音频流中的音频帧进行的解码操作是同时进行时，通过硬件解码模块和软件解码模块解码的音频帧可以是带有时序的音频帧。以根据标有的时序播放出相应的音频。

应当理解的是，本实施例中的硬件解码模块的功能可以通过DSP(Digital Signal Processing，数字信号处理)实现，实现硬件解码模块功能的软件代码可以构造于在DSP内，相应地，本实施例中音频流获取模块41、分布式控制模块42和软件解码模块的功能可以通过处理器或者控制器实现，实现上述音频流获取模块41、分布式控制模块42和软件解码模块功能的代码可以存储在存储器中并且由处理器或者控制器执行。

本实施例中提供的分布式解码控制器，还可以包括解码方式控制模块43，用于在分布式控制模块42按照分布式解码分配原则提取音频帧之前，判断待解码音频流中的音频帧的压缩比是否大于等于预设的高压缩比阈值，如是，通知分布式控制模块42按照分布式解码分配原则提取音频帧；否则，将待解码音频流中的音频帧发送至硬件解码模块或软件解码模块进行解码，具体的，可以参见图6所示。

其中，高压缩比阈值的取值范围可以是大于等于3000:1，小于等于5000:1，例如，取高压缩比阈值为3500:1，也即当判断得知待解码的音频流中音频帧的压缩比大于等于3500:1时，通知分布式控制模块42按照分布式解码分配原则提取音频帧，将经提取得到的需要通过硬解码的音频帧以及需要通过软解码的音频帧分别发送至硬件解码模块和软件解码模块进行解码；当判断得知待解码的音频流中音频帧的压缩比小于3500:1时，直接将音频流中的音频帧发送至硬件解码模块或软件解码模块进行解码，此时，可以随机地将音频流中的音频帧发送给硬件解码模块或者软件解码模块的任意一个进行解码。

应当理解的是，本实施例中的高压缩比阈值包括但不限于上述的阈值，开发人员可以根据具体的应用场景的要求具体设置。

此外，需要说明的是，上述解码方式控制模块43的功能可以通过音频终端内的处理器或者控制器实现，实现上述解码方式控制模块43功能的软件代码可以存储在存储器中并由处理器或者控制器执行。

为了在提高音频播放多样性和流畅性的同时，降低产品的生产开发成本，本实施例提供的分布式解码控制器可以模块化，生成公用的动态库以被多平台使用，如此，开发人员在开发程序时就不必每次都对这些通用的函数进行编译，可以直接通过连接程序调用动态库中的分布式解码控制器的相应代码。

具体的，可以通过如下方式生成公用的动态库：

配置Android.mk文件，设置LOCAL_MODULE(局部模块)＝ApeInsaneDecoder，引用变量include$(BUILD_SHARED_LIBRARY)；

根据配置属性，编译生成一个公用的动态库libapeInsaneDecoder.so供多个不同平台使用。

相应地，当要在系统中使用动态库libapeInsaneDecoder.so时：

在stagefright的audioparse模块引用头文件ApeInsaneDecoder.h；

在音频解析解码框架stagefright模块配置的Android.mk文件引用LOCAL_SHARED_LIBRARIES+＝libapeInsaneDecoder；

调用initApeDecoder()创建APE分布式解码器；

再调用pickAudioFrame()解析标记不同类型的音频帧；

分别调用transportToApeSoftDecoder()和transportToApeDspHwDecoder()进行相应的软解码和硬解码；

最后调用release()释放销毁APE分布式解码器。

本实施例提供的分布式解码控制器，通过音频流获取模块41获取待解码的音频流，然后分布式控制模块42按照预先设定的分布式解码分配原则，提取音频流中需要通过硬解码的音频帧以及需要通过软解码的音频帧分别发送至硬件解码模块和软件解码模块进行解码，从而使高压缩比的音频帧也能充分完成解码，使得音频的播放效果更加流畅和饱满，丰富了用户的听觉体验，提升了用户体验的满意度。

第四实施例

本实施例提供一种分布式解码控制器，包括音频流获取模块、分布式控制模块和解码方式控制模块，其中，音频流获取模块用于获取待解码的音频流；解码方式控制模块用于判断待解码音频流中的音频帧的压缩比是否大于等于预设的高压缩比阈值，如是，通知分布式控制模块按照分布式解码分配原则提取音频帧，否则，将待解码音频流中的音频帧发送至硬件解码模块或软件解码模块进行解码，本实施例中的高压缩比阈值设置为5000:1；分布式控制模块用于按照预设的分布式解码分配原则，提取音频流中需要通过硬解码的音频帧以及需要通过软解码的音频帧分别发送至硬件解码模块和软件解码模块进行解码。

应当说明的是，本实施例中的分布式解码分配原则为：交替循环的从待解码音频流的音频帧中，先依次提取N帧作为需要通过硬解码的音频帧后，再依次提取M帧作为需要通过软解码的音频帧，其中，M取大于等于1的任意整数值。N取大于M的任意整数值。

若音频流获取模块获取到的音频流是压缩格式是APEInsane的音频流，因为本实施例中的高压缩比阈值为5000:1，而APEInsane的压缩比也为5000:1，所以解码方式控制模块判断得知格式为APEInsane的待解码音频流中的音频帧的压缩比等于预设的5000:1，从而APEInsane格式的音频流会通过分布式控制模块按照预设的分布式解码分配原则，提取音频流中需要通过硬解码的音频帧以及需要通过软解码的音频帧分别发送至硬件解码模块和软件解码模块进行解码。

应当理解的是，本实施例中的硬件解码模块的功能可以通过DSP实现，实现硬件解码模块功能的软件代码可以构造于在DSP内，相应地，本实施例中音频流获取模块、分布式控制模块、解码方式控制模块、和软件解码模块的功能可以通过处理器或者控制器实现，实现上述音频流获取模块、分布式控制模块、解码方式控制模块和软件解码模块功能的代码可以存储在存储器中并且由处理器或者控制器执行。

具体的，可以定义ApeInsaneDecoder模块，ApeInsaneDecoder模块的功能对应着音频流获取模块和分布式控制模块的功能，具体用于标记不同帧数的音频帧，并分别输送至硬件解码模块和软件解码模块模块协同解码，以完成高压缩比的高复杂解码。

然后定义供ApeInsaneDecoder模块调用的接口。默认关闭解码ApeInsane格式，将开关“audio.insane.decoder.enable”默认设置为0，当ApeInsaneDecoder模块进行解码时，“audio.insane.decoder.enable”设置为1。

本实施例中，当需要对压缩格式为APEInsane的音频帧进行解码时，通过调用ApeInsaneDecoder模块的接口，访问ApeInsaneDecoder模块，将标记的不同帧数的音频帧分别输送至硬件解码模块和软件解码模块模块进行协同解码，以完成高压缩比的高复杂解码。其中，实现ApeInsaneDecoder模块功能的软件代码具体可以如下：

本实施例中的分布式解码控制器包括上述的ApeInsaneDecoder模块，为了降低产品的生产开发成本，本实施例提供的分布式解码控制器可以模块化，具体为将ApeInsaneDecoder模块生成公用的动态库以被多平台使用，如此，开发人员在开发程序时就不必每次都对这些通用的函数进行编译，可以直接通过连接程序调用动态库中的ApeInsaneDecoder模块的相应代码。

具体的，可以通过如下方式生成公用的动态库：

配置Android.mk文件，设置LOCAL_MODULE(局部模块)＝ApeInsaneDecoder，引用变量include$(BUILD_SHARED_LIBRARY)；根据配置属性，编译生成一个公用的动态库libapeInsaneDecoder.so供多个不同平台使用。

相应地，当要在系统中使用动态库libapeInsaneDecoder.so时：

在stagefright的audioparse模块引用头文件ApeInsaneDecoder.h；在音频解析解码框架stagefright模块配置的Android.mk文件引用LOCAL_SHARED_LIBRARIES+＝libapeInsaneDecoder；调用initApeDecoder()创建APE分布式解码器；再调用pickAudioFrame()解析标记不同类型的音频帧；分别调用transportToApeSoftDecoder()和transportToApeDspHwDecoder()进行相应的软解码和硬解码；最后调用release()释放销毁APE分布式解码器。

此外，本实施例提供的分布式解码控制器可以运用于安卓系统中，其在安卓系统中所处的系统框图参见图7所示。

安卓系统音频体系可以分为四个层次结构，包括应用层、Framework(架构)层、库层以及HAL(硬件抽象)层。其中，MusicPlayerApplication(音乐播放应用程序)601是整个音频体系的最上层，比如厂商根据特定需求可以自己写一个音乐播放器。Framework层包括MediaPlayer(媒体播放器)602，可以播放音乐，MediaPlayer602可以理解为客户端。而对于安卓系统本地空间的音频体系，其中一个重要的系统服务是MediaPlayerService(媒体播放服务)603，相应的MediaPlayerService603可以理解为服务器端，其主要功能是根据MediaPlayer602输入的URL调用create创建对应的Player，其中Nuplayer(播放器)623包括DataSource(数据源)604、MediaExtractor(媒体提取器)605、APEFramePicker(APE框架解析器)606、NuPlayerDecoder(实验性功能解码器)607与NuplayerRenderer(实验性功能渲染器)608。此外，DataSource604主要负责提供原始数据，MediaExtractor605将从DataSource604得到的原始数据解析成解码器需要的es数据，然后再通过APEFramePicker606将得到的es数据分别进行标记，再分别输送至APE软件解码模块和APE硬件解码模块。NuPlayerDecoder607与NuplayerRenderer608交互作用，判断是否需要进行渲染，最后可以通过AudioTrack(音频监测)609实现音频的播放，此外，AudioTrack609也可以作为Audio Flinger(音频管理器)612的客户端，AudioFlinger612是安卓系统中音频管理的中枢，Audio Flinger612中有多种对应的线程类型，例如通过OffloadThread(卸载线程)610与AudioHAL(音频硬件抽象层)613交互传递数据，通过CompressedPlatformDriver(压缩驱动平台)616和驱动器617将数据传递给解码器618进行解码，解码后的数据再先后通过内部相应的矩阵619运算、访问控制列表620和整流/回馈单元621输出音频脉冲编码调制流622，此外还可以通过AudioFlinger612中的MixerThread(混合线程)611，再通过BT HAL(蓝牙硬件抽象层)614输出堆栈数据615。

通过本实施例提供的分布式解码控制器，可以使高压缩比的音频文件能正常完成解码从而进行流畅的播放，使用户能得到更好的听觉体验。

第五实施例

本实施例基于上述分布式解码控制器71提供一种音频终端，包括硬件解码模块72、软件解码模块73以及上述任意一种分布式解码控制器71，参见图8所示，其中分布式解码控制器71用于控制将待解码音频流中的音频帧发送至硬件解码模块72和/或软件解码模块73进行解码。

应当理解的是，本实施例提供的音频终端的分布式解码控制器71可以将待解码音频流中的音频帧发送至硬件解码模块72或软件解码模块73中的任意一个模块进行解码，还可以将待解码音频流中的音频帧发送至硬件解码模块72和软件解码模块73中进行协同解码。

此外，需要说明的是，本实施例提供的音频终端包括但不限于各种智能移动终端、平板电脑、MP3、MP4等。

通过本实施例提供的音频终端，高压缩比的音频格式可以被充分及时解码，从而使得各种格式的音乐文件能播放得更加流畅，进一步丰富了用户的听觉感受，提升了用户体验的满意度。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形式，这些均属于本发明的保护之内。