[发明专利]一种Android系统中的音频播放方法

说明书

本申请公开了一种Android系统中的音频播放方法，包括：在播放配置阶段，将Android平台的TrackBuffer设为MinBuffer；其中，MinBuffer为Android平台当前需要的最小缓存数；应用识别Android平台的播放状态；所述播放状态为未播放时，持续向缓存写入音频数据；当所述播放状态为播放时，播放缓存中的音频数据。应用本申请，能够减小音频播放的延时。

技术领域

本申请涉及Android系统技术，特别涉及一种Android系统中的音频播放方法。

背景技术

在Android系统中，现有的使用Audio Track进行音频播放时，Audio Track应用与Android系统平台的交互过程如图1所示，在图1中，MinBuffer是Android平台API返回值，告知应用当前需要配置给Android平台的最小缓存数；TrackBuffer为应用最终设置给平台的缓存数，需要保证TrackBuffer＝MinBuffer；Write为应用向平台缓存中写数据，内部维护的已写数量总和；Play是Android平台API返回值，告知当前的播放进度；X是Android平台内部的缓存，应用无法感知，对不同终端该值不同，需要缓存量大于X时才真正开始播放。

基于上述交互过程实现的音频播放流程具体包括：

1)应用在播放配置阶段创建AudioTrack时，为Audio Track设置buffer大小为TrackBuffer，为了能够正常播放，通常TrackBuffer≥MinBuffer；

2)在启动播放阶段，应用向TrackBuffer中持续写入数据，当TrackBuffer被填满后AudioTrack开始播放；

3)在稳态播放过程中，当存在一帧待播放的音频数据时，应用记录已经送给平台的音频数Write，同时不断通过API获取平台的播放进度Play，判断如下：

a)若Write–Play≥TrackBuffer，则认为平台的缓存已满，不作处理；

b)若Write–PlayTrackBuffer，则认为平台缓存未满，调用API向平台写数据，同时更新已写总数Write。

4)判断若还存在待播放的音频数据，则继续执行步骤3，否则等待有新数据时再执行步骤3。

上述音频播放方式存在如下两个问题：

1、对于某些终端，当应用已经给AudioTrack的buffer填充满TrackBuffer数据后，Android平台API返回的播放进度Play并不改变，导致音频不能正常播放；其原因可能是Android平台底层的AudioFlinger还未真正启动播放，还需要TrackBuffer中的数据达到一定的缓存量X后才开始播放。为了TrackBuffer被填满后，能够真正的启动播放，通常将该buffer值设定的很大，让其大于AudioFlinger层真正启动播放需要的缓存量X。但是X的实际值对应用并不可见，只能针对不同终端去猜测X的大小。且如果为了保证能够正常播放而配置更大的TrackBuffer量，则填充TrackBuffer的时间会随之增长，势必会导致流媒体播放的用户面时延增大；

2、使用Android平台进行音频播放过程中如果连接蓝牙播放设备，可能导致音频无法继续播放。具体地，使用蓝牙设备进行音频播放时，AudioTrack需要的缓存量较大，通常大于使用Android设备自身喇叭播放时需要的TrackBuffer值。因此，当连接上蓝牙设备后，原先设给Android平台的缓存量不能满足蓝牙设备的播放。连接蓝牙设备进行音频播放所需的缓存量大小对应用不可见，且不同蓝牙设备的缓存需求量不同。如果为了保证能够正常播放而配置更大的TrackBuffer量，则填充TrackBuffer的时间会随之增长，势必会导致流媒体播放的用户面时延增大。

发明内容