CN111339351A

CN111339351A - 一种Android***中的音频播放方法

Info

Publication number: CN111339351A
Application number: CN201811555476.6A
Authority: CN
Inventors: 李智; 杨建川; 顾益双
Original assignee: Chengdu TD Tech Ltd
Current assignee: Chengdu TD Tech Ltd
Priority date: 2018-12-19
Filing date: 2018-12-19
Publication date: 2020-06-26
Anticipated expiration: 2038-12-19
Also published as: CN111339351B

Abstract

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

Description

一种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–Play<TrackBuffer，则认为平台缓存未满，调用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的时间会随之增长，势必会导致流媒体播放的用户面时延增大。

发明内容

本申请提供一种Android***中的音频播放方法，能够减小音频播放的时延。

为实现上述目的，本申请采用如下技术方案：

一种Android***中的音频播放方法，包括：

在播放配置阶段，将Android平台的TrackBuffer设为MinBuffer；其中，MinBuffer为Android平台当前需要的最小缓存数；

应用识别Android平台的播放状态；

当所述播放状态为未播放时，继续向缓存写入音频数据；当所述播放状态为播放时，播放缓存中的音频数据。

较佳地，所述应用识别Android平台的播放状态包括：

当所述应用从播放配置阶段刚进入启动播放阶段的初始场景下，所述播放状态为未播放；和/或，

在预设的第一时间段内播放进度值没有更新，则确定所述播放状态为未播放；和/或，

连续N次向TrackBuffer写入数据的间隔时间大于预设的第二时间段，则确定所述播放状态为未播放；和/或，

连续M次接收Android平台反馈的播放进度值不同，则确定所述播放状态为播放；其中，所述N和M为预设的正整数。

较佳地，该方法进一步包括：当所述播放状态为播放时，如果连续X次出现写入数据耗时超过预设的第三时间段，将缓存中剩余未播放数据量重设为TrackBuffer；其中，X为预设的正整数。

由上述技术方案可见，在播放配置阶段，将Android平台的TrackBuffer设为MinBuffer；应用识别Android平台的播放状态；当所述播放状态为未播放时，若缓存中剩余的未播放数据大于或等于预先配置的TrackBuffer，仍继续向缓存写入音频数据，以驱动Android平台进入播放状态；当所述播放状态为播放时，按照图1方式播放缓存中的音频数据。通过上述方式，不需要在配置阶段将TrackBuffer设置的过大，仍然能够保证音频的正常播放，从而减小了音频播放启动的时延。

附图说明

图1为现有的Audio Track应用与Android***平台的交互过程示意图；

图2为本申请实施例中音频播放方法的具体流程示意图。

具体实施方式

为了使本申请的目的、技术手段和优点更加清楚明白，以下结合附图对本申请做进一步详细说明。

如背景技术所述，为了使Android的音频正常播放，需要保证初始阶段Android平台缓存的数据量能够达到X。通常的方式是将TrackBuffer设置的比较大，使得TrackBuffer大于X。然而这种方式可能会导致音频播放的延时较大。

本申请中为避免出现音频播放延时过大的问题，提供一种音频播放方法。该方法具体包括：

在播放配置阶段，将Android平台的TrackBuffer设为MinBuffer；接下来在音频播放阶段，应用识别Android平台的播放状态；当播放状态为未播放时，若缓存中剩余的未播放数据大于或等于预先配置的TrackBuffer，则表明设置的TrackBuffer可能小于播放音频的最低缓存量X，这时，本申请中将继续向缓存写入音频数据，使缓存内部的数据量大于X，以触发音频播放；当播放状态为播放时，仍然按照现有的方式控制播放缓存中的音频数据。

在上述处理中，新增了应用对平台播放状态的识别机制，其中，判断平台播放状态的机制具体包括：

1)在以下场景时，判断平台播放状态为“未播放”的场景：

A.初始场景，即应用刚刚从“播放配置”阶段进入“启动播放”阶段；

B.连续预设的第一时间段内播放进度Play都不更新，如：每隔100ms判断一次，连续三次查询时，播放进度都没更新则可认为平台没有播放；

C.连续N次向TrackBuffer中填充数据的间隔时间过长，例如大于预设的第二时间段。

2)在以下场景时，判断平台播放状态为“播放”的场景：

A.连续M次平台返回的播放进度Play不一样。

上述即为应用判断平台播放状态的具体方式。

优化后应用根据平台的播放状态的数据处理机制为：

1)若平台为未播放状态：

A.当Write–Play<TrackBuffer时，正常向TrackBuffer中写入数据；

B.当Write–Play≥TrackBuffer时，强行执行写入动作。

2)若平台为播放状态：

A.音频播放相关的处理同原有的播放机制。

B.为了增强方案健壮性，在播放状态下，如果连续X次出现写入数据耗时大于预设的第三时间段，则认为平台缓存已满，强制令Write–Play＝TrackBuffer，即认为AudioTrack的可用缓存为0，避免下次继续执行数据写入耗时过长。

下面通过一个具体实施例说明本申请的具体实现。图2为本申请实施例中音频播放方法的具体流程图。该实施例是在专网终端上实现的。如图2所示，该方法包括：

步骤201，在播放配置阶段，将Android平台的TrackBuffer设为MinBuffer，并开始向AudioTrack中写入数据。

本实施例中，假定在播放配置阶段，将Android平台的TrackBuffer设为MinBuffer。

步骤202，识别平台播放状态。

步骤203，判断播放状态是否为播放，若否，则执行步骤204，若是，执行步骤205。

本实施例中，假定获取到的MinBuffer为640字节，则TrackBuffer也设置为640字节。当缓存量达到TrackBuffer大小时，音频并不会开始播放，因为平台要求960字节以上才能启动播放。那么在缓存量达到640字节后，判断播放状态为未播放，则执行步骤204。

步骤204，强行向平台写入音频数据。

通过播放进度判决Android平台为“未播放”状态，开始强行向AudioTrack中写入数据。继续强行写入320字节后，Android平台真正开始音频播放，App根据播放进度更新平台为“播放”状态。

步骤205，将平台状态标记为“播放”，按照现有方式播放音频。

在Android平台的“播放”状态下，App按照原有播放机制进行音频播放直到播放结束。

步骤206，判断平台是否有空余缓存，若是，则执行步骤207，否则，返回步骤202。

步骤207，判断距离上一次平台写入数据时间是否超过设定的时间段，若是，则执行步骤204，否则，执行步骤208。

如果在“播放”状态下平台长时间没有可播放的数据，App会再次判决平台为“未播放”状态，再次播放数据时将重复业务开始时的流程，再次触发强写机制。

步骤208，向平台写入音频数据。

步骤209，判断多次写入耗时是否过长(例如大于8ms)，若是，则执行步骤210，否则返回步骤202。

当多次写入耗时过长时，认为平台缓存已满，通过步骤210将可用缓存设为0，继续判断平台播放状态。

步骤210，将平台剩余缓存空间设为0。

上述即为本实施例中的音频播放方法的具体实现。

通过上述本申请中的音频播放方法，能够降低在Android***中播放流媒体音频时的耗时，对于用户面时延要求高的场景，该方案能够带来较为显著的时延优化效果；另外，对于某些Android终端，在音频播放过程中切换为蓝牙播放后就无声的问题可以得到解决。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。

Claims

1.一种Android***中的音频播放方法，其特征在于，包括：

应用识别Android平台的播放状态；

2.根据权利要求1所述的方法，其特征在于，所述应用识别Android平台的播放状态包括：

3.根据权利要求1所述的方法，其特征在于，该方法进一步包括：当所述播放状态为播放时，如果连续X次出现写入数据耗时超过预设的第三时间段，将缓存中剩余未播放数据量重设为TrackBuffer；其中，X为预设的正整数。