CN111339351A - Audio playing method in Android system - Google Patents

Abstract

The application discloses an audio playing method in an Android system, which comprises the following steps: in the playing configuration stage, setting a TracBuffer of the Android platform as MinBuffer; wherein MinBuffer is the minimum cache number currently required by the Android platform; identifying the playing state of the Android platform by the application; when the playing state is not playing, continuously writing audio data into the cache; and when the playing state is playing, playing the audio data in the cache. By the application, the time delay of audio playing can be reduced.

Description

Audio playing method in Android system

Technical Field

The application relates to an Android system technology, in particular to an audio playing method in an Android system.

Background

In an Android system, when an existing Audio Track is used for Audio playing, an interaction process of an Audio Track application and an Android system platform is shown in fig. 1, MinBuffer is an Android platform API return value and informs an application of a minimum cache number which needs to be configured to the Android platform at present; the TrackBuffer is a cache number finally set for the platform by the application, and the TrackBuffer is guaranteed to be MinBuffer; write is the sum of the written quantity of the application writing data into the platform cache and the internal maintenance; play is an API return value of the Android platform and informs the current playing progress; and X is a cache in the Android platform, the application cannot sense the difference, and the playing is really started when the cache amount is larger than X for different terminals.

The audio playing process implemented based on the above interaction process specifically includes:

1) when the application creates an AudioTrack in a playing configuration stage, setting the buffer size of the AudioTrack as TrackBuffer, and generally, the TrackBuffer is more than or equal to MinBuffer in order to normally play;

2) in the playing starting stage, the application continuously writes data into the TrackBuffer, and the AudioTrack starts playing after the TrackBuffer is filled;

3) in the steady-state playing process, when a frame of audio data to be played exists, the application records the audio number Write sent to the platform, and continuously obtains the playing progress Play of the platform through the API, and the judgment is as follows:

a) if the Write-Play is larger than or equal to the TrackBuffer, the buffer of the platform is considered to be full, and the processing is not carried out;

b) and if the Write-Play is less than the TrackBuffer, the platform cache is considered to be not full, the API is called to Write data to the platform, and the total written Write is updated.

4) And (3) if the audio data to be played still exist, continuing to execute the step (3), otherwise, executing the step (3) again when new data exist.

The audio playing method has the following two problems:

1. for some terminals, after the application fills the buffer of the AudioTrack with the track buffer data, the playing progress returned by the Android platform API is not changed, so that the audio cannot be played normally; the reason may be that the AudioFlinger at the bottom layer of the Android platform does not really start playing yet, and the playing is started only after the data in the TrackBuffer reaches a certain buffer amount X. In order to actually start the playback after the TrackBuffer is filled, the buffer value is usually set to be large, so that the buffer value is larger than the buffer amount X required by the AudioFlinger layer to actually start the playback. However, the actual value of X is not applicable, and X can only be guessed for different terminals. If a larger TrackBuffer amount is configured to ensure normal playing, the time for filling the TrackBuffer will increase, which inevitably results in an increase in the user plane delay of streaming media playing;

2. if the Bluetooth playing device is connected in the process of playing the audio by using the Android platform, the audio cannot be played continuously. Specifically, when the bluetooth device is used for audio playing, the buffer amount required by the AudioTrack is large, and is usually larger than the TrackBuffer value required when the Android device is used for speaker playing. Therefore, after the bluetooth device is connected, the buffer amount originally set for the Android platform cannot meet the playing requirement of the bluetooth device. The buffer memory size required for audio playing by connecting the Bluetooth equipment is invisible to the application, and the buffer memory demand of different Bluetooth equipment is different. If a larger TrackBuffer amount is configured to ensure normal playing, the time for filling the TrackBuffer will increase, which inevitably results in an increase in the user plane delay of streaming media playing.

Disclosure of Invention

The application provides an audio playing method in an Android system, which can reduce the time delay of audio playing.

In order to achieve the purpose, the following technical scheme is adopted in the application:

an audio playing method in an Android system comprises the following steps:

in the playing configuration stage, setting a TracBuffer of the Android platform as MinBuffer; wherein MinBuffer is the minimum cache number currently required by the Android platform;

identifying the playing state of the Android platform by the application;

when the playing state is not played, continuously writing audio data into the cache; and when the playing state is playing, playing the audio data in the cache.

Preferably, the identifying the playing state of the Android platform by the application includes:

when the application just enters an initial scene of a playing starting stage from a playing configuration stage, the playing state is not played; and/or the presence of a gas in the gas,

if the playing progress value is not updated within a preset first time period, determining that the playing state is not played; and/or the presence of a gas in the gas,

if the interval time for continuously writing data into the TrackBuffer for N times is longer than a preset second time period, determining that the playing state is not played; and/or the presence of a gas in the gas,

if the playing progress values fed back by the Android platform are received for M times continuously and are different, determining that the playing state is playing; wherein, N and M are preset positive integers.

Preferably, the method further comprises: when the playing state is playing, if the time consumed for writing data for X times exceeds a preset third time period, resetting the amount of the remaining unplayed data in the cache to be a TrackBuffer; wherein X is a preset positive integer.

According to the technical scheme, in the playing configuration stage, the TrackBuffer of the Android platform is set as MinBuffer; identifying the playing state of the Android platform by the application; when the playing state is not played, if the remaining unplayed data in the cache is greater than or equal to a preconfigured TrackBuffer, audio data are still continuously written into the cache to drive the Android platform to enter the playing state; and when the playing state is playing, playing the audio data in the cache according to the mode of figure 1. By the mode, the normal playing of the audio can still be ensured without excessively setting the TrackBuffer in the configuration stage, so that the time delay of starting the audio playing is reduced.

Drawings

FIG. 1 is a schematic diagram illustrating an interaction process between an existing Audio Track application and an Android system platform;

fig. 2 is a schematic flowchart of an audio playing method in an embodiment of the present application.

Detailed Description

For the purpose of making the objects, technical means and advantages of the present application more apparent, the present application will be described in further detail with reference to the accompanying drawings.

As described in the background art, in order to normally play the Android audio, it is required to ensure that the data amount cached by the Android platform at an initial stage can reach X. The usual way is to set the TrackBuffer larger so that TrackBuffer is larger than X. However, this approach may result in a large delay in audio playback.

In order to avoid the problem of overlarge audio playing delay, the application provides an audio playing method. The method specifically comprises the following steps:

in the playing configuration stage, setting a TracBuffer of the Android platform as MinBuffer; next, in an audio playing stage, identifying the playing state of the Android platform by an application; when the playing state is not playing, if the remaining unplayed data in the cache is greater than or equal to the preconfigured TrackBuffer, it indicates that the set TrackBuffer may be smaller than the lowest buffer size X of the played audio, at this time, the audio data is continuously written into the cache, so that the data volume in the cache is greater than X, to trigger audio playing; when the playing state is playing, the audio data in the playing buffer is still controlled according to the existing mode.

In the above processing, an identification mechanism of the application to the platform playing state is added, wherein the mechanism for judging the platform playing state specifically includes:

1) when the following scenes exist, judging the playing state of the platform as a scene of 'not playing':

A. an initial scene, namely, an application just enters a 'start playing' stage from a 'playing configuration' stage;

B. the playing progress Play is not updated in the first time period which is continuously preset, such as: judging once every 100ms, and when the query is continuously carried out for three times, if the playing progress is not updated, the platform can be considered to be not played;

C. the interval between N consecutive times of filling the TrackBuffer with data is too long, for example, greater than a preset second time period.

2) When the following scenes exist, the playing state of the platform is judged to be the scene of 'playing':

A. the playing progress playbacks returned by the platform for M consecutive times are different.

The above is a specific way for determining the playing state of the platform by the application.

The optimized data processing mechanism of the application according to the playing state of the platform is as follows:

1) if the platform is in the non-playing state:

A. when Write-Play < TrackBuffer, data is normally written into the TrackBuffer;

B. when Write-Play is equal to or greater than TrackBuffer, the Write operation is forced.

2) If the platform is in a playing state:

A. the audio playing related processing is the same as the original playing mechanism.

B. In order to enhance the robustness of the scheme, in the playing state, if the time consumed for writing data is greater than a preset third time period for X times, the platform buffer is considered to be full, and Write-Play is forced to be a track buffer, that is, the available buffer of the AudioTrack is considered to be 0, so that the time consumed for continuously writing data next time is avoided to be too long.

The following describes a specific implementation of the present application with a specific embodiment. Fig. 2 is a specific flowchart of an audio playing method in the embodiment of the present application. The embodiment is implemented on a private network terminal. As shown in fig. 2, the method includes:

step 201, in the playing configuration phase, setting the TrackBuffer of the Android platform as MinBuffer, and starting to write data into the AudioTrack.

In this embodiment, it is assumed that, in the play configuration stage, the TrackBuffer of the Android platform is set to MinBuffer.

Step 202, identify a platform play status.

Instep 203, it is determined whether the playback status is playback, if not, step 204 is executed, and if so,step 205 is executed.

In this embodiment, assuming that the acquired MinBuffer is 640 bytes, the TrackBuffer is also set to be 640 bytes. When the buffer size reaches the TrackBuffer size, the audio does not start playing because the platform requires more than 960 bytes to start playing. Then after the buffer amount reaches 640 bytes, the playing status is determined to be not played, and step 204 is executed.

Step 204, forcibly writing the audio data into the platform.

And judging that the Android platform is in an 'unplayed' state through the playing progress, and forcibly writing data into the AudioTrack. And after the 320 bytes are continuously forcibly written, the Android platform really starts audio playing, and the App updates the platform to be in a playing state according to the playing progress.

Step 205, mark the platform state as "play", and play the audio according to the existing mode.

In the 'playing' state of the Android platform, the App plays audio according to the original playing mechanism until the playing is finished.

Step 206, judging whether the platform has a free cache, if so, executingstep 207, otherwise, returning to step 202.

Step 207, determining whether the time from the last time of writing data into the platform exceeds a set time period, if so, executingstep 204, otherwise, executingstep 208.

If the platform has no playable data for a long time in the 'playing' state, the App can judge the platform to be in the 'not playing' state again, and when the data is played again, the process when the service starts is repeated, and the strong writing mechanism is triggered again.

Step 208, write the audio data to the platform.

Step 209 determines whether the time consumed for writing many times is too long (e.g., greater than 8ms), if so,step 210 is executed, otherwise,step 202 is returned to.

When the time consumed by the multiple writing is too long, the platform cache is considered to be full, the available cache is set to 0 throughstep 210, and the platform playing state is continuously judged.

Step 210, set the remaining buffer space of the platform to 0.

The foregoing is a specific implementation of the audio playing method in this embodiment.

By the audio playing method, time consumption for playing the streaming media audio in the Android system can be reduced, and for scenes with high time delay requirements on the user plane, the scheme can bring a remarkable time delay optimization effect; in addition, for some Android terminals, the problem that the Android terminal is silent after being switched to Bluetooth playing in the audio playing process can be solved.

The above description is only for the purpose of illustrating the preferred embodiments of the present invention and is not to be construed as limiting the invention, and any modifications, equivalents, improvements and the like made within the spirit and principle of the present invention should be included in the scope of the present invention.

Claims (3)

1. An audio playing method in an Android system is characterized by comprising the following steps:

in the playing configuration stage, setting a TracBuffer of the Android platform as MinBuffer; wherein MinBuffer is the minimum cache number currently required by the Android platform;

identifying the playing state of the Android platform by the application;

when the playing state is not played, continuously writing audio data into the cache; and when the playing state is playing, playing the audio data in the cache.

2. The method according to claim 1, wherein the application recognizing the play state of the Android platform comprises:

when the application just enters an initial scene of a playing starting stage from a playing configuration stage, the playing state is not played; and/or the presence of a gas in the gas,

if the playing progress value is not updated within a preset first time period, determining that the playing state is not played; and/or the presence of a gas in the gas,

if the interval time for continuously writing data into the TrackBuffer for N times is longer than a preset second time period, determining that the playing state is not played; and/or the presence of a gas in the gas,

if the playing progress values fed back by the Android platform are received for M times continuously and are different, determining that the playing state is playing; wherein, N and M are preset positive integers.

3. The method of claim 1, further comprising: when the playing state is playing, if the time consumed for writing data for X times exceeds a preset third time period, resetting the amount of the remaining unplayed data in the cache to be a TrackBuffer; wherein X is a preset positive integer.

Images