CN116684521A - 音频处理方法、设备及存储介质 - Google Patents

Abstract

本申请提供了一种音频处理方法、设备及存储介质。该方法在向第一缓存区中每次写入音频数据后，通过写入第一时间阈值和第一写数据时间，从而每次从第一缓存区中读取音频数据时，根据读取音频数据时的系统时间，以及第一缓存区中记录的第一时间阈值和第一写数据时间就能够及时预知音频数据是否出现了断流现象，从而在没有检测到淡出标记时，也能够及时执行淡出流程，将音量逐渐调整为0，有效避免了POP音的产生。

Description

音频处理方法、设备及存储介质

技术领域

本申请涉及音频处理技术领域，尤其涉及一种音频处理方法、设备及存储介质。

背景技术

POP音产生原因在于，音量变化太大导致有POP音，目前的解决方式是以淡入淡出的方式调节音量。所谓淡入淡出指的是声音在开始播放时音量由低到高，在结束时慢慢变小至0，从而避免音量突然变化，如一开始播放声音就很大，或者从很高的音量突然变为0，给用户带来较差的听觉体验。

其中，淡出功能的实现，需要在感知到音频暂停(如按下暂停键)、播放器退出、切换音频(如按下切换键)时才能触发，在没有提前感知到上述触发条件时，如果音频数据断流依旧会导致POP音产生。

发明内容

为了解决上述技术问题，本申请提供一种音频处理方法、设备及存储介质，旨在提前感知音频数据流是否会突然断流，进而在确定音频数据流即将断流前采用淡出方式调节音量，从而避免POP音产。

第一方面，本申请提供一种音频处理方法。该方法包括：第一线程循环调用写函数，将接收到的第一音频数据写入第一缓存区，并在每次调用写函数将接收到的第一音频数据写入第一缓存区后，计算第一时间阈值，将第一时间阈值写入第一缓存区，将当前系统时间作为第一写数据时间写入第一缓存区；第二线程通过与第一线程对应的第一声道，从第一缓存区中读取M个采样点的第一音频数据；其中，第一声道每次从第一缓存区中读取M个采样点的第一音频数据时，获取当前系统时间作为第一读数据时间，并在第一读数据时间与第一写数据时间之间的第一时间差不小于第一时间阈值时，对M个采样点的第一音频数据和第一缓存区中剩余的N个采样点的第一音频数据做音量的淡出处理，M和N均为正整数；第二线程将淡出处理后的M个采样点的第一音频数据和N个采样点的第一音频数据传输至音频驱动，由音频驱动驱动音频模块播放M个采样点的第一音频数据和N个采样点的第一音频数据。

其中，第一线程例如下文所说的与应用程序层中播放音乐的应用程序，如音乐(Application，APP)对应的用于产生音频数据的媒体播放实例，其可以为AudioTrack，也可以为MediaPlayer。关于第一线程为AudioTrack或MediaPlayer时，对音频数据的格式要求，解码处理可参见下文，此处不再赘述。

其中，写函数，例如下文所说的write()。

其中，第一缓存区，例如下文所说的在AudioTrackShared中为第一线程分配的一块Buffer。

其中，第一时间阈值在一些实现方式中可以是下文中所说的threshold_time，在另一些实现方式中也可以是下文中所说的average_time，在另一些实现方式中还可以是threshold_time和average_time。

其中，第一写数据时间，例如是下文所说的last_write_time。

其中，第二线程例如是下文所说的PlayBackThread。

其中，第一声道，例如为下文中所说的与AudioTrack对应的Track。

可理解的，应用程序层中启动的用于播放音频数据的APP，与AudioTrack、Track是一一对应的，并且不同的APP提供的音频数据，在通过AudioTrack写入AudioTrackShared时，会为其分配对应的Buffer，如下文所说的音乐APP对应的AudioTrack为AudioTrack(1)，Buffer为Buffer1，Track为Track(1)，而短信APP对应的AudioTrack为AudioTrack(2)，Buffer为Buffer2，Track为Track(2)。

其中，M如下文所说的mFrameCount。

由此，在向第一缓存区中每次写入音频数据后，通过写入第一时间阈值和第一写数据时间，从而每次从第一缓存区中读取音频数据时，根据读取音频数据时的系统时间，以及第一缓存区中记录的第一时间阈值和第一写数据时间就能够及时预知音频数据是否出现了断流现象，从而在没有检测到淡出标记时，也能够及时执行淡出流程，将音量逐渐调整为0，有效避免了POP音的产生。

根据第一方面，第一时间阈值包括指示第一缓存区中的第一音频数据被读取完所需的第一消耗时间阈值；计算第一时间阈值，包括：第一线程在每次调用写函数将接收到的第一音频数据写入第一缓存区时，获取第一缓存区当前剩余的采样点的第一数据量；第一线程根据第一数据量和本次要写入的第一音频数据包括的采样点的第二数据量，确定写入第二数据量的第一音频数据后，第一缓冲区剩余的采样点的第三数据量；第一线程根据第三数量和M，确定第一缓存区中所说第三数据量的第一音频数据供第二线程通过第一声道读取的次数；第一线程根据第二线程每次通过第一声道从第一缓存区中读取M个采样点的的第一音频数据的读数据周期和次数，计算出第一耗时时间阈值。

其中，第一消耗时间阈值，即为下文所说的threshold_time，第一数据量为下文所说的filledFrameCount，第二数据量为下文所说的writenFrameCount，第三数据量即(writenFrameCount+filledFrameCount)，读数据周期为下文所说的timePeriod。关于根据mFrameCount(也就是M)、filledFrameCount、writenFrameCount、timePeriod这四个参数计算threshold_time的方式详见下文，此处不再赘述。

根据第一方面，或者以上第一方面的任意一种实现方式，第一时间阈值包括指示第一线程每次调用写函数将接收到的第一音频数据写入第一缓存区的第一平均写数据周期；计算第一时间阈值，包括：第一线程在每次调用写函数将接收到的第一音频数据写入第一缓存区时，获取第一缓存区当前记录的第一写数据时间和第一平均写数据周期；第一线程获取当前系统时间，计算当前系统时间和当前记录的第一写数据时间之间的时间差；第一线程对时间差和当前记录的第一平均写数据周期做平均处理，计算出本次调用写函数将接收到的第一音频数据写入第一缓存区后，要写入第一缓存区中的第一平均写数据周期。

其中，第一平均写数据周期例如为下文中的average_time，关于根据前一次调用写函数向第一缓存区写入音频数据后记录的average_time和last_write_time，以及本次调用写函数向第一缓存区写入音频数据后的系统时间确定最新的average_time的方式可详见下文，此处不再赘述。

根据第一方面，或者以上第一方面的任意一种实现方式，第一时间阈值包括指示第一缓存区中的第一音频数据被读取完所需的第一消耗时间阈值，以及指示第一线程每次调用写函数将接收到的第一音频数据写入第一缓存区的第一平均写数据周期；计算第一时间阈值，包括：第一线程在每次调用写函数将接收到的第一音频数据写入第一缓存区时，获取第一缓存区当前剩余的采样点的第一数据量；第一线程根据第一数据量和本次要写入的第一音频数据包括的采样点的第二数据量，确定写入第二数据量的第一音频数据后，第一缓冲区剩余的采样点的第三数据量；第一线程根据第三数量和M，确定第一缓存区中所说第三数据量的第一音频数据供第二线程通过第一声道读取的次数；第一线程根据第二线程每次通过第一声道从第一缓存区中读取M个采样点的的第一音频数据的读数据周期和次数，计算出第一耗时时间阈值；第一线程在每次调用写函数将接收到的第一音频数据写入第一缓存区时，获取第一缓存区当前记录的第一写数据时间和第一平均写数据周期；第一线程获取当前系统时间，计算当前系统时间和当前记录的第一写数据时间之间的时间差；第一线程对时间差和当前记录的第一平均写数据周期做平均处理，计算出本次调用写函数将接收到的第一音频数据写入第一缓存区后，要写入第一缓存区中的第一平均写数据周期。

根据第一方面，或者以上第一方面的任意一种实现方式，对M个采样点的第一音频数据和第一缓存区中剩余的N个采样点的第一音频数据做音量的淡出处理，包括：当第一缓存区中剩余的(M+N)个采样点的第一音频数据满足设定要求时，第一声道对M个采样点的第一音频数据和第一缓存区中剩余的N个采样点的第一音频数据做音量的淡出处理。

由此，在计算出的时间差不小于第一缓存区中记录的第一时间阈值时，进一步判断第一缓存区中当前剩余的第一音频数据的数据量是否满足执行淡出流程的个数，在满足时在执行，从而能够避免开始执行淡出操作时剩余的数量太多，导致用户感知到音量的变化，也可以避免剩余的数量太少导致POP音出现。即，通过判断是否满足设定条件，进而确定开始执行淡出处理的位置，从而既可以避免POP音出现，又能让用户无感知。

根据第一方面，或者以上第一方面的任意一种实现方式，满足设定要求为(M+N)≤(M*7/4)。

具体示例可参见下文，此处不再赘述。

根据第一方面，或者以上第一方面的任意一种实现方式，做音量的淡出处理，包括：在第一读数据时间与第一写数据时间之间的第一时间差不小于第一时间阈值，且第一缓存区中剩余的(M+N)个采样点的第一音频数据满足设定要求时，第一声道获取第一缓存区中读第一音频数据位置处的第一音频数据对应的音量值；对于(M+N)个采样点的第一音频数据的音量值，从第一个采样点的第一音频数据开始至第(M+N)个采样点的第一音频数据，将音量值均匀递减至0。

由此，在执行淡出处理时，能够平稳的将音量值递减至0，避免音量变化差值过大，影响用户听觉体验。

根据第一方面，或者以上第一方面的任意一种实现方式，M的取值根据第一音频数据的格式和音频模块的硬件参数确定。

根据第一方面，或者以上第一方面的任意一种实现方式，第一缓存区为环形共享内存。

由此，根据边读边写的需求，使得内存可以循环使用，降低为每一个APP分配的Buffer的大小。

根据第一方面，或者以上第一方面的任意一种实现方式，方法还包括：第三线程循环调用写函数，将接收到的第二音频数据写入第二缓存区，并在每次调用写函数将接收到的所示第二音频数据写入第二缓存区后，计算第二时间阈值，将第二时间阈值写入第二缓存区，将当前系统时间作为第二写数据时间写入第二缓存区；第二线程通过与第三线程对应的第二声道，从第二缓存区中读取X个采样点的第二音频数据；其中，第二声道每次从第二缓存区中读取X个采样点的第二音频数据时，获取当前系统时间作为第二读数据时间，并在第二读数据时间与第二写数据时间之间的第二时间差不小于第二时间阈值时，对X个采样点的第二音频数据和第二缓存区中剩余的Y个采样点的第二音频数据做音量的淡出处理，X和Y均为正整数；第二线程将淡出处理后的M个采样点的第一音频数据和N个采样点的第一音频数据，以及X个采样点的第二音频数据和Y个采样点的第二音频数据进行混音处理，得到混音数据；第二线程将混音数据传输至音频驱动，由音频驱动驱动音频模块播放混音数据。

其中，第三线程例与第一线程类似，均是用于作为产生音频数据的媒体播放实例。

其中，第二声道即为与第三线程对应的Track。

其中，X即为一次读取操作获取的采样点的数量，通M，即可以表示为下文所说的mFrameCount。

可理解的，不同APP提供的音频数据由不同的AudioTrcak调用写函数写如不同的Buffer，即每一条音频数据的写入都是独立的，在写入Buffer的过程中，对应的声道均会在每次调用写函数写入音频数据后，在Buffer中写入对应的时间阈值和写数据时间，如第一线程写入第一缓存区的是第一时间阈值和第一写数据时间，第三线程写入第二缓存区的是第二时间阈值和第二写数据时间。

示例性的，第二时间阈值可以与第一时间阈值包括的参数类型相同，也可以不相同。均可以是threshold_time和average_time中的任意一个或多个。

由此，在向第二缓存区中每次写入音频数据后，通过写入第二时间阈值和第二写数据时间，从而每次从第二缓存区中读取音频数据时，根据读取音频数据时的系统时间，以及第二缓存区中记录的第二时间阈值和第二写数据时间就能够及时预知音频数据是否出现了断流现象，从而在没有检测到淡出标记时，也能够及时执行淡出流程，将音量逐渐调整为0，有效避免了POP音的产生。

此外，第二线程在同一时刻接收到多个声道传输来的音频数据时，通过将多个有音频数据进行混音处理，从而能够将多个音频数据融为一体，同时播放。

根据第一方面，或者以上第一方面的任意一种实现方式，第二缓存区为环形共享内存。由此，根据边读边写的需求，使得内存可以循环使用，降低为每一个APP分配的Buffer的大小。

根据第一方面，或者以上第一方面的任意一种实现方式，方法还包括：在第一读数据时间与第一写数据时间之间的第一时间差小于第一时间阈值时，第一声道识别到第一缓存区中记录了淡出标记时，对M个采样点的第一音频数据和第一缓存区中剩余的N个采样点的第一音频数据做音量的淡出处理。

其中，淡出标记如下文所说的Stopped标记、Terminated标记、FadeOutFlushTimes、forceRampToZero＝0等，关于触发AudioTrack向对应的Buffer中添加这些标记的方式详见下文，此处不再赘述。

由此，通过将添加淡出标记和上述添加时间阈值(第一时间阈值、第二时间阈值等)、写数据时间(第一写数据时间、第二写数据时间等)的方式相融合，在实际应用中，在满足图3a至图3c所示的音频处理方法中的淡出流程的执行条件(检测到淡出标记)，根据写数据时间和当前系统时间计算出的时间差超过时间阈值，且缓存区中剩余的音频数据的数据量满足设定要求的任意一项，均可以执行淡出流程。例如，在时间差没有超过时间阈值，但检测到上述任意一种淡出标记时，可触发执行淡出流程。具体实现细节可以参见下文关于这两种方案的描述部分，此处不再赘述。

根据第一方面，或者以上第一方面的任意一种实现方式，在第一线程循环调用写函数之前，方法还包括：在应用程序层中的第一应用程序启动之后，实例化第一线程、第一声道、第二线程；第一线程请求共享内存分配第一缓冲区，并记录第一缓存区的地址信息；响应作用于第一应用程序中对第一音频文件的播放请求，播放请求携带了第一音频文件的标识信息，标识信息包括第一音频文件的文件名和存储路径；第一应用程序从存储路径中查找文件名的第一音频文件；其中，第一线程循环调用写函数，将接收到的第一音频数据写入第一缓存区，包括：第一线程循环调用写函数，从第一音频文件中读取第一音频数据，并将第一音频数据写入第一缓存区。

根据第一方面，或者以上第一方面的任意一种实现方式，标识信息还包括第一音频文件中第一音频数据的采样率；第一线程循环调用写函数，从第一音频文件中读取第一音频数据，并将第一音频数据写入第一缓存区，包括：在第一音频数据的采样率与第一声道从第一缓存区中读取音频数据的采样率不匹配时，对第一音频文件中的第一音频数据进行重采样；第一线程循环调用写函数，从重采样后的第一音频文件中读取第一音频数据，并将第一音频数据写入第一缓存区。

第二方面，本申请提供了一种电子设备。该电子设备包括：存储器和处理器，存储器和处理器耦合；存储器存储有程序指令，程序指令由处理器执行时，使得所述电子设备执行第一方面或第一方面的任意可能的实现方式中的方法的指令。

第二方面以及第二方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第二方面以及第二方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

第三方面，本申请提供了一种计算机可读介质，用于存储计算机程序，该计算机程序包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的指令。

第三方面以及第三方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第三方面以及第三方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

第四方面，本申请提供了一种计算机程序，该计算机程序包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的指令。

第四方面以及第四方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第四方面以及第四方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

第五方面，本申请提供了一种芯片，该芯片包括处理电路、收发管脚。其中，该收发管脚、和该处理电路通过内部连接通路互相通信，该处理电路执行第一方面或第一方面的任一种可能的实现方式中的方法，以控制接收管脚接收信号，以控制发送管脚发送信号。

第五方面以及第五方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第五方面以及第五方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

附图说明

图1为示例性示出的电子设备的硬件结构示意图；

图2为示例性示出的电子设备的软件结构示意图；

图3a至图3c为示例性示出的一种音频处理方法的示意图；

图4为示例性示出的又一种音频处理方法的示意图；

图5为示例性示出的音频波形示意图；

图6为示例性示出的对音频波形放大一定倍数后的采样点示意图；

图7为示例性示出的单一个音频处理的示意图；

图8为示例性示出的多个音频进行混音处理的示意图；

图9为示例性示出的对2个音频进行混音处理后的音频波形示意图；

图10为示例性示出的又一种音频处理方法的示意图；

图11为示例性示出的又一种音频处理方法的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。

本申请实施例的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。例如，第一目标对象和第二目标对象等是用于区别不同的目标对象，而不是用于描述目标对象的特定顺序。

在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

在本申请实施例的描述中，除非另有说明，“多个”的含义是指两个或两个以上。例如，多个处理单元是指两个或两个以上的处理单元；多个系统是指两个或两个以上的系统。

本申请实施例提供的音频处理方法可以应用于手机、平板电脑、可穿戴设备、车载设备、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本、个人数字助理(personal digital assistant，PDA)等电子设备上，本申请实施例对电子设备的具体类型不作任何限制。

示例性的，图1是本申请实施例提供的一种电子设备100的结构示意图。电子设备100可以包括：处理器110，外部存储器接口120，内部存储器121，通用串行总线(universalserial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块(subscriber identification module，SIM)卡接口195等。

示例性的，在一些实现方式中，传感器模块180可以包括压力传感器，陀螺仪传感器，气压传感器，磁传感器，加速度传感器，距离传感器，接近光传感器，指纹传感器，温度传感器，触摸传感器，环境光传感器，骨传导传感器等，此处不再一一例举，本申请对此不作限制。

具体到本申请实施例提供的技术方案中，触发音频的淡出功能的条件的感知，例如可以是通过压力传感器、触摸传感器等检测到的数据确定用户是否对暂停键、退出键等进行了操作，如点击擦着。关于利用传感器感知用户触摸位置、触摸力度，进而确定实际操作的控件，作出对应响应的实现细节，此处不再赘述。

此外，需要说明的是，处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processing unit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

可理解的，控制器可以是电子设备100的神经中枢和指挥中心。在实际应用中，控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

此外，还需要说明的是，处理器110中还可以设置存储器，用于存储指令和数据。在一些实现方式中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。

示例性的，在一些实现方式中，处理器110可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，I2C)接口，集成电路内置音频(inter-integrated circuit sound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purpose input/output，GPIO)接口，用户标识模块(subscriber identitymodule，SIM)接口，和/或通用串行总线(universal serial bus，USB)接口等。

继续参见图1，示例性的，充电管理模块140用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。在一些有线充电的实现方式中，充电管理模块140可以通过USB接口130接收有线充电器的充电输入。在一些无线充电的实现方式中，充电管理模块140可以通过电子设备100的无线充电线圈接收无线充电输入。充电管理模块140为电池142充电的同时，还可以通过电源管理模块141为电子设备供电。

继续参见图1，示例性的，电源管理模块141用于连接电池142，充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入，为处理器110，内部存储器121，外部存储器，显示屏194，摄像头193，和无线通信模块160等供电。电源管理模块141还可以用于监测电池容量，电池循环次数，电池健康状态(漏电，阻抗)等参数。在其他一些实现方式中，电源管理模块141也可以设置于处理器110中。在另一些实现方式中，电源管理模块141和充电管理模块140也可以设置于同一个器件中。

继续参见图1，示例性的，电子设备100的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。

需要说明的是，天线1和天线2用于发射和接收电磁波信号。电子设备100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实现方式中，天线可以和调谐开关结合使用。

继续参见图1，示例性的，移动通信模块150可以提供应用在电子设备100上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块150还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实现方式中，移动通信模块150的至少部分功能模块可以被设置于处理器110中。在一些实现方式中，移动通信模块150的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。

此外，需要说明的是，调制解调处理器可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。随后解调器将解调得到的低频基带信号传送至基带处理器处理。低频基带信号经基带处理器处理后，被传递给应用处理器。应用处理器通过音频设备(不限于扬声器170A，受话器170B等)输出声音信号，或通过显示屏194显示图像或视频。在一些实现方式中，调制解调处理器可以是独立的器件。在另一些实现方式中，调制解调处理器可以独立于处理器110，与移动通信模块150或其他功能模块设置在同一个器件中。

继续参见图1，示例性的，无线通信模块160可以提供应用在电子设备100上的包括无线局域网(wireless local area networks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigation satellitesystem，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near fieldcommunication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。无线通信模块160可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块160经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

具体到本申请实施例提供的技术方案中，电子设备100可通过移动通信模块150或无线通信模块160与云端服务器或者其他服务器进行通信，进而获取需要播放的音频数据。示例性的，云端可以是多个服务器组成的服务器集群。

此外，还需要说明的是，电子设备100通过GPU，显示屏194，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

继续参见图1，示例性的，显示屏194用于显示图像，视频等。显示屏194包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)，有机发光二极管(organic light-emitting diode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrix organic light emitting diode的，AMOLED)，柔性发光二极管(flex light-emitting diode，FLED)，Miniled，MicroLed，Micro-oLed，量子点发光二极管(quantum dot light emitting diodes，QLED)等。在一些实现方式中，电子设备100可以包括1个或N个显示屏194，N为大于1的正整数。

此外，还需要说明的是，电子设备100可以通过ISP，摄像头193，视频编解码器，GPU，显示屏194以及应用处理器等实现拍摄功能。

此外，还需要说明的是，ISP用于处理摄像头193反馈的数据。例如，拍照时，打开快门，光线通过镜头被传递到摄像头感光元件上，光信号转换为电信号，摄像头感光元件将所述电信号传递给ISP处理，转化为肉眼可见的图像。ISP还可以对图像的噪点，亮度，肤色进行算法优化。ISP还可以对拍摄场景的曝光，色温等参数优化。在一些实现方式中，ISP可以设置在摄像头193中。

此外，还需要说明的是，摄像头193用于捕获静态图像或视频。物体通过镜头生成光学图像投射到感光元件。感光元件可以是电荷耦合器件(charge coupled device，CCD)或互补金属氧化物半导体(complementary metal-oxide-semiconductor，CMOS)光电晶体管。感光元件把光信号转换成电信号，之后将电信号传递给ISP转换成数字图像信号。ISP将数字图像信号输出到DSP加工处理。DSP将数字图像信号转换成标准的RGB，YUV等格式的图像信号。在一些实现方式中，电子设备100可以包括1个或N个摄像头193，N为大于1的正整数。

此外，还需要说明的是，数字信号处理器用于处理数字信号，除了可以处理数字图像信号，还可以处理其他数字信号。例如，当电子设备100在频点选择时，数字信号处理器用于对频点能量进行傅里叶变换等。

此外，还需要说明的是，视频编解码器用于对数字视频压缩或解压缩。电子设备100可以支持一种或多种视频编解码器。这样，电子设备100可以播放或录制多种编码格式的视频，例如：动态图像专家组(moving picture experts group，MPEG)1，MPEG2，MPEG3，MPEG4等。

继续参见图1，示例性的，外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展电子设备100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。

继续参见图1，示例性的，内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，从而执行电子设备100的各种功能应用以及数据处理。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储电子设备100使用过程中所创建的数据(比如音频数据，电话本等)等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flashstorage，UFS)等。

此外，还需要说明的是，电子设备100可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，以及应用处理器等实现音频功能。例如音乐播放，录音等。

具体到本申请实施例提供的技术方案中，对音频数据进行的淡出处理，可以根据程序指令慢慢调小音量至0，从而使得音频模块170播放的音量逐渐变小为0。

此外，还需要说明的是，音频模块170用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。音频模块170还可以用于对音频信号编码和解码。在一些实现方式中，音频模块170可以设置于处理器110中，或将音频模块170的部分功能模块设置于处理器110中。

继续参见图1，示例性的，按键190包括开机键，音量键等。按键190可以是机械按键。也可以是触摸式按键。电子设备100可以接收按键输入，产生与电子设备100的用户设置以及功能控制有关的键信号输入。

继续参见图1，示例性的，马达191可以产生振动提示。马达191可以用于来电振动提示，也可以用于触摸振动反馈。例如，作用于不同应用(例如拍照，音频播放等)的触摸操作，可以对应不同的振动反馈效果。作用于显示屏194不同区域的触摸操作，马达191也可对应不同的振动反馈效果。不同的应用场景(例如：时间提醒，接收信息，闹钟，游戏等)也可以对应不同的振动反馈效果。触摸振动反馈效果还可以支持自定义。

继续参见图1，示例性的，指示器192可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。

关于电子设备100的硬件结构就介绍到此，应当理解的是，图1所示电子设备100仅是一个范例，在具体实现中，电子设备100可以具有比图中所示的更多的或者更少的部件，可以组合两个或多个的部件，或者可以具有不同的部件配置。图1中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。

为了更好的理解图1所示电子设备100的软件结构，以下对电子设备100的软件结构进行说明。在对电子设备100的软件结构进行说明之前，首先对电子设备100的软件系统可以采用的架构进行说明。

具体的，在实际应用中，电子设备100的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。

此外，可理解的，目前主流的电子设备使用的软件系统包括但不限于Windows系统、Android系统和iOS系统。为了便于说明，本申请实施例以分层架构的Android系统为例，示例性说明电子设备100的软件结构。

此外，后续关于本申请实施例提供的技术方案，在具体实现中同样适用于其他系统。

参见图2，为本申请实施例的电子设备100的软件结构框图。

如图2所示，电子设备100的分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实现方式中，将Android系统分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(Android runtime)和系统库，以及内核层。

其中，应用程序层可以包括一系列应用程序包。

如图2所示，应用程序包可以包括设置、音乐、地图、WLAN、蓝牙、相机、短信等应用程序(application，APP)，此处不再一一列举，本申请对此不作限制。

具体到本申请实施例提供的技术方案中，开启淡入淡出的方式调节音量的功能可以通过设置APP提供的功能入口实现，淡入淡出功能可以是在使用音乐APP(同上文所说的播放器)播放音频数据时触发。具体实现细节详见下文，此处不再赘述。

其中，应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。在一些实现方式中，这些编程接口和编程框架可以描述为函数。

如图2所示，应用程序框架层可以包括音频系统、视图系统、内容提供器、窗口管理器、电话管理器等函数，此处不再一一列举，本申请对此不作限制。

具体到本申请实施例提供的技术方案中，音频系统可用于管理、创建各种实例、服务、进程、线程等，如用于充当音频数据生产者的媒体播放实例(如AudioTrack)、用于缓存AudioTrack生产的音频数据的共享内存(如AudioTrackShared，可理解为一个环形队列)、用于将AudioTrackShared中的音频数据传输给音频驱动的播放线程(如PlayBackThread)，以及用于连通AudioTrackShared和PlayBackThread并与AudioTrack对应的声道(Track)。

应当理解的是，上述由音频系统管理、创建的各种实例、服务、进程、线程等，仅为实现本申请实施例提供的技术方案所需的部分实例、服务、进程、线程，关于音频数据的接收、播放过程中涉及到的其他实例、服务、进程、线程等，此处不再列举。

此外，需要说明的是，在实际应用中充当音频数据生产者的媒体播放实例也可以是MediaPlayer。

其中，AudioTrack与MediaPlayer最大的区别在于，MediaPlayer可以播放多种格式的音频数据，例如MP3，AAC，WAV，OGG，MIDI等，在具体实现时，MediaPlayer会在应用程序框架层创建对应的音频解码器，从而实现对不同格式的音频数据的解码，进而将其写入共享缓存中，以便后播放线程通过对应的Track从共享缓存中读取音频数据传输给音频驱动，进而驱动对应的音频模块播放音频数据。

而AudioTrack不会在应用程序框架层创建解码器，只能播放已经解码的PCM流，如WAV格式的音频数据(WAV格式的音频数据通常为PCM流)。本申请实施例以创建的音频数据生产者为AudioTrack为例。

此外，还需要说明的是，上述位于应用程序框架层中的视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。

此外，还需要说明的是，上述位于应用程序框架层中的内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等，此处不再一一列举，本申请对此不作限制。

此外，还需要说明的是，上述位于应用程序框架层中的窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。

此外，还需要说明的是，上述位于应用程序框架层中的电话管理器用于提供电子设备100的通信功能。例如通话状态的管理(包括接通，挂断等)。

可理解的，上述个功能模块也可以表示为服务、框架，本实施例对此不作限制。

继续参见图2，其中Android Runtime包括核心库和虚拟机。Android Runtime负责安卓系统的调度和管理。

核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。

应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，三维(3D)图形处理库(例如：OpenGL ES)，二维(2D)图形引擎(例如：SGL)等。

表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。

媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如：MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。

三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。

可理解的，上述所说的2D图形引擎是2D绘图的绘图引擎。

此外，可理解的，Android系统中的内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动等。示例性的，传感器驱动可用于将传感器(例如触摸传感器)的检测信号输出至视图系统，以使得视图系统响应于检测信号，显示对应的应用界面。

关于电子设备100的软件结构就介绍到此，可以理解的是，图2示出的软件结构中的层以及各层中包含的部件，并不构成对电子设备100的具体限定。在本申请另一些实施例中，电子设备100可以包括比图示更多或更少的层，以及每个层中可以包括更多或更少的部件，本申请不做限定。

为了便于理解，本申请以下实施例将以具有图1和图2所示结构的电子设备为例，结合附图和应用场景，对本申请实施例提供的音频处理方法进行具体阐述。

目前，用户可通过电子设备如手机中安装的音视频APP，如音乐APP、视频APP播放音频文件(音频数据)。示例性的，在一些实现方式中，当用户对手机桌面上显示的音乐APP的图标进行操作(如点击操作)，手机响应于该用户操作，打开该音乐APP对应的操作界面，如显示歌曲的清单页面，或者搜索歌曲的页面，并在应用程序框架层创建媒体播放实例，如AudioTrack。在AudioTrack创建并启动后，可以进一步创建与该音乐APP对应的AudioTrack对应的Track，具体可以是在AudioTrack接收到start指令，或者调用start函数时实现。

进一步地，在完成上述操作后，为了保证PlayBackThread能够准确的获取不同APP对应的AudioTrack写入AudioTrackShared中的音频数据，Track会将标识自身唯一性的识别号(后续用户Track_id表示)传输给PlayBackThread进行管理，以便PlayBackThread能够根据Track_id确定从AudioTrackShared中获取音频数据的Track。

可理解的，PlayBackThread的创建可以是在创建AudioTrack时进行的，也可以是在创建AudioTrack后进行的，具体可以参见音频系统的相关文档，此处不再赘述。

此外，可理解的，在完成上述操作后，PlayBackThread可以向AudioTrack作出响应，以便AudioTrack获知已完成播放音频数据的前期准备工作。

相应地，如果在设定时间内没有接收到，则可以重新发送start指令，以重新执行上述流程。

示例性的，当用户在显示歌曲的清单页面，或者搜索歌曲的页面中进行操作选中要播放的歌曲(后续统一称为音频数据)，并对播放该音频数据的控件如播放控件进行操作，手机响应于该操作行为，该音乐APP通过其对应的AudioTrack开始向AudioTrackShared中写入音频数据，如调用写函数，如write()。

可理解的，在通过AudioTrack向AudioTrackShared中写音频数据时，需要先获取AudioTrackShared中指定的一块缓存空间(Buffer)。相应地，在AudioTrackShared向AudioTrack反馈为其分配的Buffer的地址信息，如开始地址和结束地址后，AudioTrack重复调用write()，向指定的Buffer中写入音频数据。

如图3a所示，示例性的，图中示出的环形队列即为AudioTrackShared，其中区域1至区域8可以看作AudioTrackShared为AudioTrack分片的Buffer。在AudioTrack重复调用write()向该Buffer中写音频数据时，第一次调用write函数会从图中“读音频数据位置F”处开始写音频数据，随着音频数据的写入，写音频数据的位置逐级后移，如图中当写到区域8时，写音频数据的位置移动到图中“写音频数据位置R”处。

继续参见图3a，示例性的，当音频数据写完区域8，停留在图中R处时，若用户对界面中提供的暂停键，或者退出该界面的退出键，或者该音乐APP出现异常闪退导致对应的AudioTrack被杀死(kill)，基于目前的淡出功能的实现原理，会在该AudioTrack对应的Buffer中，具体为R处添加一个淡出标记。

需要说明的是，AudioTrack在向Buffer写音频数据的过程中，PlayBackThread也会通过该AudioTrack对应的Track从该Buffer中读音频数据。如图3a所示，PlayBackThread通过该AudioTrack对应的Track从该Buffer中首次读取音频数据时，会从图中F处的位置开始读取，示例性的，如果此时Buffer中的数据还没有写到图中的R位置，在AudioTrack重复调用write()的过程，会按序向Buffer区域中写入音频数据，每一次调用write()，其写音频数据的位置为前一次的写音频数据结束位置后的地址。

参见图3b，示例性的，如果PlayBackThread通过该AudioTrack对应的Track从该Buffer中一次读取了区域1中的全部音频数据，则下一次读取音频数据的位置F移动到图3b所示位置。

示例性的，按照上述读、写逻辑，如果在图3c中的R处写入了淡出标记，此时读取音频数据的位置F移动到了图3c中的位置，当PlayBackThread通过该AudioTrack对应的Track从图3c中示出的位置F处再次读取音频数据时，Track检测到位置R处添加的淡出标记，如果当前剩余的音频数据量满足淡出的条件，则对当前播放的音乐的音量进行淡出调整，例如对位置F处的音频数据的音量逐渐调低，直到播放到位置R处的音频数据时音量变为0。

可理解的，音频数据的读取、写入都是毫秒级的，因此当检测到位置R处存在淡出标记时，从图3c中的位置F处开始对应音量进行淡出调整，对用户而言不会有明显感知，但可以有效解决POP音的问题，从而改善用户听觉体验。

关于上文所说的淡出标记，在实际应用中可以根据具体的触发原因添加不同的标记。示例性的，在一些实现方式中，淡出标记例如为用于标识AudioTrack发生中断的中断标识，其可通过调用判断中断的函数，如isTerminated()确定AudioTrack是否发生中断。相应地，若通过isTerminated()确定AudioTrack发生中断，则可以在图3a中的R处添加中断标记，如用Terminated表示。

示例性的，在另一些实现方式中，淡出标记例如为用于标识用户对暂停键、退出键进行了操作，使得AudioTrack停止向对应的Buffer写音频数据的操作的停止标识，其可通过调用判断是否停止的函数，如isStopped()确定AudioTrack是否停止写音频数据的操作。相应地，若通过isStopped()确定AudioTrack停止写音频数据的操作，则可以在图3a中的R处添加停止标记，如用Stopped表示。

示例性的，在另一些实现方式中，淡出标记例如为用于标识部分音频数据被清除的标记，其可通过调用清除音频数据函数，如FadeOut FlushTimes()告知Track，Buffer中缓存的音频数据从哪一位置/时间开始执行淡出。需要说明的是，该标记为AudioTrack根据某些预设机制自动添加到图3a中R处的，其可用FadeOut FlushTimes表示。

此外，需要说明的是，在实际应用中，对于上述场景添加的淡出标记可以统一为“forceRampToZero＝0”，这样Track在从Buffer中读取音频数据时，如果检测到Buffer中出现了该标记，则确定要对播放的音频数据进行淡出的调音处理。即，不论上述那种触发原因，只要轮询上述函数识别到forceRampToZero＝0，则确定要对播放的音频数据进行淡出的调音处理。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

然而，在实际应用中，可能存在音乐APP因为某种情况，导致音频数据突然断流，而其对应的AudioTrack依旧处于活跃状态(active)，如某些三方APP复用一个AudioTrack播放多个音频数据，这种情况下，在暂停、退出、切换等操作时，不会调用上述几种判断是否添加了淡出标记的函数，AudioTrack也不会在对应的Buffer中添加对应的淡出标记，而是直接停止向Buffer中写音频数据，即音频数据会直接断流。对于这种场景，上述触发淡出的方案就无法提前感知到，进而导致PlayBackThread不会对音频数据进行淡出处理，进而造成播放完区域8中的音频数据后，音量突然降为0，进而导致POP音出现。

有鉴于此，本申请实施例提供了一种音频处理方法，旨在提前感知音频数据是否会突然断流，即在缓存空间中还有音频数据时就感知到断流情况发生，进而在确定音频数据出现断流后，提前在断流位置前采用淡出方式调节剩余要播放的音频数据的音量，从而避免POP音产生。

示例性的，在一种实现方式中，位于应用程序层的音视频APP，如上文所说的音乐APP播放歌曲时，在按照上述实例化好AudioTrack、AudioTrackShared、Track和PlayBackThread后，音乐APP每次调用AudioTrack中的write()向AudioTrackShared中为其分配的Buffer写入音频数据后，均执行一次获取当前系统时间，并将当前系统时间作为标记写入本次写入的音频数据之后的位置，后续将该时间标记表示为last_write_time。

此外，为了减少冗余，同时避免Buffer中存在多个last_write_time，导致Tracke根据last_write_time进行的处理出现异常，在下次调用AudioTrack中的write()向AudioTrackShared中为其分配的Buffer写音频数据时，该记录last_write_time的位置将被复用，作为本次写入音频数据的起始位置。相应地，在写入本次音频数据后，在本次写入的音频数据之后的位置，再次添加新的系统时间last_write_time。

此外，在每一次调用write()向对应的Buffer写入音频数据后，AudioTrack还需要根据本次写的音频数据的数据量(后续用writenFrameCount表示)、本次写操作之前写入Buffer中剩余的音频数据的数据量(后续用filledFrameCount表示)，以及PlayBackThread每次通过Track从对应Buffer中读取的音频数据的数据量(后续用mFrameCount表示)、PlayBackThread通过Track从Buffer读取音频数据的周期(后续用timePeriod表示)，计算一个判断是否触发淡出的时间阈值(后续用户threshold_time表示)，并将该threshold_time一同写入本次调用write()写入Buffer的音频数据后。即，每调用一次write()向Buffer中写入音频数据后，在本次写入的音频数据后均写入last_write_time和threshold_time。

关于根据writenFrameCount、filledFrameCount、mFrameCount和timePeriod确定threshold_time时，可遵循threshold_time＝(writenFrameCount+filledFrameCount)/mFrameCount*timePeriod。

需要说明的是，上述所说的数据量具体到实际应用中可理解为音频数据中的采样点，即每次读取、写入的采样点数量。

此外，需要说明的是，mFrameCount与要读取的音频数据的格式，以及电子设备播放音频数据的硬件设备自身的参数信息相关。硬件设备自身的参数信息可以直接获取，音频数据的格式在读取音频数据时可以获知，因此根据这些已知的信息可以确定mFrameCount，而timePeriod也为固定已知的，因此在每次写完音频数据后，根据Buffer中当前剩余的可读取的音频数据的数据量(writenFrameCount+filledFrameCount)，以及已知的mFrameCount和timePeriod，就可以计算出读取完当前剩余的可读取的音频数据的数据量所需要的时间阈值threshold_time。

此外，需要说明的是，在实际应用中，如果电子设备支持的采样率与当前读取的音频数据格式对应的采样率不匹配，可以先对音频数据进行重采样，将其转换为电子设备支持的采样率，然后在写入Buffer中。

此外，可理解的，由于读、写操作是可以同时进行的，因此在音乐APP调用AudioTrack中的write()向AudioTrackShared中为其分配的Buffer写音频数据的过程中，PlayBackThread会通过对应的Track从AudioTrackShared中为音乐APP对应的AudioTrack分配的Buffer中读取音频数据，并获取Buffer中记录的last_write_time、threshold_time，以及当前的系统时间。进而根据last_write_time和当前的系统时间确定二者的时间差是否超过(可以包含等于的情况)threshold_time。

相应地，若计算出的时间差超过threshold_time，则表明当前音频数据出现了断流现象，此时即便没有检测到淡出标记，为了避免出现POP音，也可开始执行淡出流程。

进一步地，为了避免淡出流程开始执行的时间过早，导致用户感知到音量从高到低的变化，或者淡出流程开始执行的时间过晚，音量降为0的时间太短，导致POP音依旧出现。在计算出的时间差超过threshold_time时，可以进一步判断AudioTrackShared中对应Buffer内剩余的音频数据的数据量是否满足设定要求，如是否足够PlayBackThread通过Track从该Buffer中读取一次，但不超过两次。具体到实际应用中，判断是否满足设定要求可以检查framesReady≤(desiredFrames*7/4)是否成立。

关于上述判断条件中的framesReady用于指示当前已准备好的音频数据的数据量，即计算出的时间差超过threshold_time时，Buffer中剩余的音频数据的数据量；desiredFrames用于指示本次计划处理的音频数据的数据量，即本次要读取的音频数据的数据量。

示例性的，以desiredFrames为40个采样点为例，当计算出的时间差超过threshold_time时，Buffer中的framesReady不超过70个时，则可以开始执行淡出流程。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

此外，需要说明的是，本实施例提供的音频处理方法可以与上述图3a至图3c示出的音频处理方法相融合。即，在实际应用中，在满足图3a至图3c所示的音频处理方法中的淡出流程的执行条件(检测到淡出标记)，本实施例中时间差超过threshold_time，且framesReady满足设定要求的任意一项，均可以执行淡出流程。例如，在时间差没有超过threshold_time，但检测到上述任意一种淡出标记时，可触发执行淡出流程。

对于本实施例提供的音频处理方法，具体到实际应用中，其实现可如图4所示。参见图4，示例性的，AudioTrackShared中为音乐APP对应的AudioTrack分配的Buffer中，区域7为最近一次调用write()写入的音频数据的数据量(writenFrameCount)，区域1至区域6为历史写入Buffer的音频数据的数据量(filledFrameCount)，在向区域7写完音频数据后，将获取到的当前系统时间last_write_time，以及按照上述方式确定的threshold_time写入图4中“写音频数据位置R”处的空间。如果PlayBackThread通过Track从图4中“读音频数据位置F”处读音频数据时，未检测到上文所说的淡出标记，在读取本次的desiredFrames时，根据当前的系统时间和从Buffer中的last_write_time计算出的时间差超过从Buffer中的threshold_time时，则进一步判断是否满足开始执行淡出流程的设定要求。

示例性的，以图4中区域1至区域7中每一个区域内写入的采样点数量相同为例，若本次计划处理的desiredFrames为4个区域的采样点，即区域1至区域7的采样点，根据上述判断条件确定，Buffer当前已经准备好的framesReady(区域1至区域8中的采样点)满足开始执行淡出流程的设定要求，Track在将读取的音频数据传输给PlayBackThread时，会告知从哪一个采样点开始执行淡出流程。

可理解的，在实际应用中，需要播放的音频数据的音频波形可如图5所示，该音频波形图的横坐标可为对应的播放时间，纵坐标可为音量，对于图5所示音频波形放大一定的倍数后，可以看到其每一区域的波形变化都是由多个采样点的音量高低变化导致的。对于图5中某一区域放大一定的倍数后的波形图可如图6所示，其中图6中每一个点代表了一个采样点。

根据上述描述，在执行淡出流程时，音量的调节可以根据执行淡出流程的位置处采样点的音量值，以及执行淡出流程的位置到断流位置(最后一个采样点的位置)之间包括的采样点数量(包括两个端点)，合理调整每一个采样点下降的音量。例如，在淡出流程的位置处采样点的音量值为10，之间的采样点数量为10时，可以以每播放一个采样点降低1音量值的递减方式调节音量，直至播放完最后一个采样点的数据后，音量降为0。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

此外，需要说明的是，关于正常播放过程中每个采样点的音量值，以及开始执行淡出时每个采样点的音量值的调整，是由AudioTrackShared中准备阶段对应的函数，如prepareTrack_l实现的，而将读取到并由prepareTrack_l处理后的音频数据传输给音频驱动的操作是由AudioTrackShared中循环写入音频驱动的函数，如threadLoop_write实现的。

参见图7，示例性的，prepareTrack_l对自己持有的Track进行音量设置，如将正常播放的音量值设置为10，若Track从AudioTrackShared中识别到淡出标记，或者根据last_write_time和当前系统时间确定时间差超过threshold_time，并且经判断满足如上述所说的执行淡出流程的设定要求时，AudioTrackShared中有10个采样点，分别为音量数据1至音频数据10，Track根据当前的音量值和剩余的采样点数量确定音量条件策略，如每一个采样点对应的音量值降低1，基于这一处理原则，Track会将音频数据1的音量值从10调整为9(将调整后的音频数据1称为音频数据1’)，则经Track调整音量值后的音频数据1’会传输给threadLoop_write，由threadLoop_write将音频数据1’传输给音频驱动，进而使得音频驱动能够驱动音频模块以音量值为9的音量播放音频数据1’。

继续参见图7，示例性的，对于音频数据2，基于上述处理原则，Track会将音频数据2的音量值从10调整为8(将调整后的音频数据2称为音频数据2’)，则经Track调整音量值后的音频数据2’会传输给threadLoop_write，由threadLoop_write将音频数据2’传输给音频驱动，进而使得音频驱动能够驱动音频模块以音量值为8的音量播放音频数据2’。对于音频数据3至音频数据10，按照上述处理原则进行处理，则最终Track会将音频数据10的音量值从10调整为1(将调整后的音频数据10称为音频数据10’)，则经Track调整音量值后的音频数据10’会传输给threadLoop_write，由threadLoop_write将音频数据10’传输给音频驱动，进而使得音频驱动能够驱动音频模块以音量值为1的音量播放音频数据10’，由于后续没有音频数据了，因此以音量值1播放完音量数据1’后，音量就会变为0，从而实现了淡出效果，避免了POP音产生。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

此外，可理解的，上述说明是以单个音频数据的处理过程进行说明的，在实际应用中，可能存在同时有多个音频数据播放的情况，如在播放音乐的过程中，接收到了短信消息，如果手机处于响铃模式，则会发出提示音。对于这种多个音频数据同时播放的场景，PlayBackThread还会对多个音频数据进行混音处理，具体可以通过混音函数，如threadLoop_mix实现。

参见图8，示例性的，音乐APP在播放音乐的过程中会对应一个AudioTrack，如图中的AudioTrack(1)，短信APP在接收到短信作出提示音时也会启动一个AudioTrack，如图中的AudioTrack(2)。而不同的AudioTrack会对应不同的Track，如图中AudioTrack(1)对应Track(1)，AudioTrack(2)对应Track(2)。

此外，为了便于管理不同APP产生的音频数据，在AudioTrackShared中也可为不同的AudioTrack分配不同的Buffer，如图8中为AudioTrack(1)分配Buffer1，为AudioTrack(2)分配Buffer2。

继续参见图8，示例性的，在某一时刻写入AudioTrack(1)写入Buffer1的音频数据为图中音频数据A，此时短信APP接收到信息后作出的提示音的音频数据为图中的音频数据8，则这两个音频数据会通过各自对应的AudioTrack写入对应的Buffer中，其写入过程中对last_write_time和threshold_time的添加如上文所述，此处不再赘述。

继续参见图8，示例性的，PlayBackThread会根据记录的Track(1)的Track_id调用Track(1)从Buffer1中读取音频数据A，记录的Track(2)的Track_id调用Track(2)从Buffer2中读取音频数据B。具体是由上文所说的prepareTrack_l对其持有的Track(Track(1)、Track(2))进行遍历，进而根据用户或系统为音乐APP设置音量值和短信APP设置音量值，分别设置Track(1)、Track(2)对应的正常播放音量值，具体实现方式可参见上文，此处不再赘述。

示例性的，在识别到淡出标记或满足本实施例提供的音频处理方法的条件时，则可以由Track对获取到的音频数据进行音量调整。可理解的，由于AudioTrack、Buffer、Track是一一对应的，因此每个AudioTrack对应的Buffer中均可能存在淡出标记或满足本实施例提供的音频处理方法的条件，因此各自对应的Track会在满足执行淡出流程时，分别对各自对应的音频数据进行淡出处理。图8以音频数据A和音频数据B均不需要执行淡出处理为例，对于这种情况，prepareTrack_l会将从Track(1)获取到的音频数据A和从Track(2)获取到的音频数据B传输至threadLoop_mix，由threadLoop_mix对音频数据A和音频数据B进行混音处理，进而得到混音后的音频数据AB，最终将音频数据AB传输至threadLoop_write，由threadLoop_write将音频数据AB传输给音频驱动，进而使得音频驱动能够驱动音频模块以对应的音量值播放音频数据AB。

参见图9，示例性的，以图9中(1)示出的音频波形为音频数据A的波形图，图9中(2)示出的音频波形为音频数据B的波形图，如果音频数据A和音频数据B均示在T1时间内产生的，经threadLoop_mix进行混音处理后得到的音频数据AB的音频波形图可如图9中(3)所示。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

由此，本申请实施例提供的音频处理方法，在向缓存空间中每次写入音频数据后，通过写入上文所说的last_write_time和threshold_time，从而每次从缓存空间中读取音频数据时，根据读取音频数据时的系统时间，以及缓存空间中记录的last_write_time和threshold_time就能够及时预知音频数据是否出现了断流现象，从而在没有检测到淡出标记时，也能够及时执行淡出流程，将音量逐渐调整为0，有效避免了POP音的产生。

示例性的，在一种实现方式中，位于应用程序层的音视频APP，如上文所说的音乐APP播放歌曲时，在按照上述实例化好AudioTrack、AudioTrackShared、Track和PlayBackThread后，音乐APP每次调用AudioTrack中的write()向AudioTrackShared中为其分配的Buffer写入音频数据后，均执行一次获取当前系统时间，并将当前系统时间作为标记写入本次写入的音频数据之后的位置，后续将该时间标记表示为last_write_time。

此外，为了减少冗余，同时避免Buffer中存在多个last_write_time，导致Tracke根据last_write_time进行的处理出现异常，在下次调用AudioTrack中的write()向AudioTrackShared中为其分配的Buffer写音频数据时，该记录last_write_time的位置将被复用，作为本次写入音频数据的起始位置。相应地，在写入本次音频数据后，在本次写入的音频数据之后的位置，再次添加新的系统时间last_write_time。

此外，在每一次调用write()向对应的Buffer写入音频数据后，AudioTrack还需要根据当前系统时间，即上述所说的last_write_time(此处表示为last_write_time(i)，上一次写入音频数据时添加的系统时间(表示为last_write_time(i-1))，第(i-1)次调用write写音频数据后得出的平均写数据周期averageTime(i-1)，确定本次调用write写音频数据后的平均写数据周期averageTime(i)，并将本次计算出的averageTime(i)一同写入本次调用write()写入Buffer的音频数据后。即，每调用一次write()向Buffer中写入音频数据后，在本次写入的音频数据后均写入last_write_time(i)和averageTime(i)。

关于根据last_write_time(i-1)、last_write_time(i)和averageTime(i-1)确定averageTime(i)时，可遵循averageTime(i)＝(last_write_time(i)-last_write_time(i-1)+averageTime(i-1))/2。

同理，由于读、写操作是可以同时进行的，因此在音乐APP调用AudioTrack中的write()向AudioTrackShared中为其分配的Buffer写音频数据的过程中，PlayBackThread会通过对应的Track从AudioTrackShared中为音乐APP对应的AudioTrack分配的Buffer中读取音频数据，并获取Buffer中记录的last_write_time(i)、averageTime(i)，以及当前的系统时间。进而根据last_write_time(i)和当前的系统时间确定二者的时间差是否超过(可以包含等于的情况)averageTime(i)。

相应地，若计算出的时间差超过averageTime(i)，则表明AudioTrack停止向对应的Buffer写入音频数据，即当前音频数据出现了断流现象，此时即便没有检测到淡出标记，为了避免出现POP音，也可开始执行淡出流程。

进一步地，为了避免淡出流程开始执行的时间过早，导致用户感知到音量从高到低的变化，或者淡出流程开始执行的时间过晚，音量降为0的时间太短，导致POP音依旧出现。在计算出的时间差超过averageTime(i)时，可以进一步判断AudioTrackShared中对应Buffer内剩余的音频数据的数据量是否满足设定要求，如是否足够PlayBackThread通过Track从该Buffer中读取一次，但不超过两次。具体到实际应用中，判断是否满足设定要求依旧可以是检查framesReady≤(desiredFrames*7/4)是否成立。关于判断是否满足设定要求，并根据判断结果决定是否执行淡出流程，以及淡出流程的具体实现细节可参见上述实施例，此处不再赘述。

此外，需要说明的是，本实施例提供的音频处理方法同样可以与上述图3a至图3c示出的音频处理方法相融合。即，在实际应用中，在满足图3a至图3c所示的音频处理方法中的淡出流程的执行条件(检测到淡出标记)，本实施例中时间差超过averageTime(i)，且framesReady满足设定要求的任意一项，均可以执行淡出流程。例如，在时间差没有超过averageTime(i)，但检测到上述任意一种淡出标记时，可触发执行淡出流程。

对于本实施例提供的音频处理方法，具体到实际应用中，其实现可如图10所示。参见图10，示例性的，AudioTrackShared中为音乐APP对应的AudioTrack分配的Buffer中，区域7为最近一次调用write()写入的音频数据的数据量，区域1至区域6为历史写入Buffer的音频数据的数据量，在向区域7写完音频数据后，将获取到的当前系统时间last_write_time(如上文所说的last_write_time(i))，以及按照上述方式确定的averageTime(如上文所说的averageTime(i))写入图10中“写音频数据位置R”处的空间。如果PlayBackThread通过Track从图10中“读音频数据位置F”处读音频数据时，未检测到上文所说的淡出标记，在读取本次的desiredFrames时，根据当前的系统时间和从Buffer中的last_write_time计算出的时间差超过从Buffer中的averageTime时，则进一步判断是否满足开始执行淡出流程的设定要求。

示例性的，以图10中区域1至区域7中每一个区域内写入的采样点数量相同为例，若本次计划处理的desiredFrames为4个区域的采样点，即区域1至区域7的采样点，根据上述判断条件确定，Buffer当前已经准备好的framesReady(区域1至区域8中的采样点)满足开始执行淡出流程的设定要求，Track在将读取的音频数据传输给PlayBackThread时，会告知从哪一个采样点开始执行淡出流程。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

由此，本申请实施例提供的音频处理方法，在向缓存空间中每次写入音频数据后，通过写入上文所说的last_write_time和average_time，从而每次从缓存空间中读取音频数据时，根据读取音频数据时的系统时间，以及缓存空间中记录的last_write_time和average_time就能够及时预知音频数据是否出现了断流现象，从而在没有检测到淡出标记时，也能够及时执行淡出流程，将音量逐渐调整为0，有效避免了POP音的产生。

示例性的，在一种实现方式中，位于应用程序层的音视频APP，如上文所说的音乐APP播放歌曲时，在按照上述实例化好AudioTrack、AudioTrackShared、Track和PlayBackThread后，音乐APP每次调用AudioTrack中的write()向AudioTrackShared中为其分配的Buffer写入音频数据后，均执行一次获取当前系统时间，并将当前系统时间作为标记写入本次写入的音频数据之后的位置，后续将该时间标记表示为last_write_time。同时，还可以根据上述实施例给出的确定threshold_time的方式，确定本次写入音频数据后对应的threshold_time，以及根据上述实施例给出的确定average_time的方式，确定本次写入音频数据后对应的average_time，并将threshold_time和average_time这两个参数也一同写入本次调用write()写入Buffer的音频数据后。即，每调用一次write()向Buffer中写入音频数据后，在本次写入的音频数据后均写入last_write_time、threshold_time和average_time。

相应地，PlayBackThread在通过Track从AudioTrackShared中为音乐APP对应的AudioTrack分配的Buffer中读取音频数据时，可以将上述三个参数获取到，并根据当前的系统时间，确定当前的系统时间与last_write_time之间的时间差是否超过threshold_time和average_time。

示例性的，在一些实现方式中，可以规定在时间差超过threshold_time，也超过average_time时，执行淡出流程。

示例性的，在另一些实现方式中，可以规定在时间差超过threshold_time，或者超过average_time时，执行淡出流程。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

由此，本申请实施例提供的音频处理方法，在向缓存空间中每次写入音频数据后，通过写入上文所说的last_write_time、threshold_time和average_time，从而每次从缓存空间中读取音频数据时，根据读取音频数据时的系统时间，以及缓存空间中记录的last_write_time、threshold_time和average_time就能够及时预知音频数据是否出现了断流现象，从而在没有检测到淡出标记时，也能够及时执行淡出流程，将音量逐渐调整为0，有效避免了POP音的产生。

此外，可以理解的是，电子设备为了实现上述功能，其包含了执行各个功能相应的硬件和/或软件模块。结合本文中所公开的实施例描述的各示例的算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以结合实施例对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

此外，需要说明的是，在实际的应用场景中由电子设备实现的上述各实施例提供的音频处理方法，也可以由电子设备中包括的一种芯片系统来执行，其中，该芯片系统可以包括处理器。该芯片系统可以与存储器耦合，使得该芯片系统运行时调用该存储器中存储的计算机程序，实现上述电子设备执行的步骤。其中，该芯片系统中的处理器可以是应用处理器也可以是非应用处理器的处理器。

另外，本申请实施例还提供一种计算机可读存储介质，该计算机存储介质中存储有计算机指令，当该计算机指令在电子设备上运行时，使得电子设备执行上述相关方法步骤实现上述实施例中的音频处理方法。

另外，本申请实施例还提供了一种计算机程序产品，当该计算机程序产品在电子设备上运行时，使得电子设备执行上述相关步骤，以实现上述实施例中的音频处理方法。

另外，本申请的实施例还提供一种芯片(也可以是组件或模块)，该芯片可包括一个或多个处理电路和一个或多个收发管脚；其中，所述收发管脚和所述处理电路通过内部连接通路互相通信，所述处理电路执行上述相关方法步骤实现上述实施例中的音频处理方法，以控制接收管脚接收信号，以控制发送管脚发送信号。

此外，通过上述描述可知，本申请实施例提供的电子设备、计算机可读存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (16)

1.一种音频处理方法，其特征在于，所述方法包括：

第一线程循环调用写函数，将接收到的第一音频数据写入第一缓存区，并在每次调用所述写函数将接收到的所述第一音频数据写入所述第一缓存区后，计算第一时间阈值，将所述第一时间阈值写入所述第一缓存区，将当前系统时间作为第一写数据时间写入所述第一缓存区；

第二线程通过与第一线程对应的第一声道，从所述第一缓存区中读取M个采样点的第一音频数据；其中，所述第一声道每次从所述第一缓存区中读取M个采样点的第一音频数据时，获取当前系统时间作为第一读数据时间，并在所述第一读数据时间与所述第一写数据时间之间的第一时间差不小于所述第一时间阈值时，对所述M个采样点的第一音频数据和所述第一缓存区中剩余的N个采样点的第一音频数据做音量的淡出处理，M和N均为正整数；

所述第二线程将淡出处理后的所述M个采样点的第一音频数据和所述N个采样点的第一音频数据传输至音频驱动，由所述音频驱动驱动音频模块播放所述M个采样点的第一音频数据和所述N个采样点的第一音频数据。

2.根据权利要求1所述的方法，其特征在于，所述第一时间阈值包括指示所述第一缓存区中的第一音频数据被读取完所需的第一消耗时间阈值；

所述计算第一时间阈值，包括：

所述第一线程在每次调用所述写函数将接收到的所述第一音频数据写入所述第一缓存区时，获取所述第一缓存区当前剩余的采样点的第一数据量；

所述第一线程根据所述第一数据量和本次要写入的第一音频数据包括的采样点的第二数据量，确定写入所述第二数据量的第一音频数据后，所述第一缓冲区剩余的采样点的第三数据量；

所述第一线程根据所述第三数量和所述M，确定所述第一缓存区中所说第三数据量的第一音频数据供所述第二线程通过所述第一声道读取的次数；

所述第一线程根据所述第二线程每次通过第一声道从所述第一缓存区中读取M个采样点的的第一音频数据的读数据周期和所述次数，计算出所述第一耗时时间阈值。

3.根据权利要求1所述的方法，其特征在于，所述第一时间阈值包括指示所述第一线程每次调用所述写函数将接收到的所述第一音频数据写入所述第一缓存区的第一平均写数据周期；

所述计算第一时间阈值，包括：

所述第一线程在每次调用所述写函数将接收到的所述第一音频数据写入所述第一缓存区时，获取所述第一缓存区当前记录的第一写数据时间和第一平均写数据周期；

所述第一线程获取当前系统时间，计算所述当前系统时间和当前记录的第一写数据时间之间的时间差；

所述第一线程对所述时间差和当前记录的第一平均写数据周期做平均处理，计算出本次调用所述写函数将接收到的所述第一音频数据写入所述第一缓存区后，要写入所述第一缓存区中的所述第一平均写数据周期。

4.根据权利要求1所述的方法，其特征在于，所述第一时间阈值包括指示所述第一缓存区中的第一音频数据被读取完所需的第一消耗时间阈值，以及指示所述第一线程每次调用所述写函数将接收到的所述第一音频数据写入所述第一缓存区的第一平均写数据周期；

所述计算第一时间阈值，包括：

所述第一线程在每次调用所述写函数将接收到的所述第一音频数据写入所述第一缓存区时，获取所述第一缓存区当前剩余的采样点的第一数据量；

所述第一线程根据所述第一数据量和本次要写入的第一音频数据包括的采样点的第二数据量，确定写入所述第二数据量的第一音频数据后，所述第一缓冲区剩余的采样点的第三数据量；

所述第一线程根据所述第三数量和所述M，确定所述第一缓存区中所说第三数据量的第一音频数据供所述第二线程通过所述第一声道读取的次数；

所述第一线程根据所述第二线程每次通过第一声道从所述第一缓存区中读取M个采样点的的第一音频数据的读数据周期和所述次数，计算出所述第一耗时时间阈值；

所述第一线程在每次调用所述写函数将接收到的所述第一音频数据写入所述第一缓存区时，获取所述第一缓存区当前记录的第一写数据时间和第一平均写数据周期；

所述第一线程获取当前系统时间，计算所述当前系统时间和当前记录的第一写数据时间之间的时间差；

所述第一线程对所述时间差和当前记录的第一平均写数据周期做平均处理，计算出本次调用所述写函数将接收到的所述第一音频数据写入所述第一缓存区后，要写入所述第一缓存区中的所述第一平均写数据周期。

5.根据权利要求1至4任一项所述的方法，其特征在于，所述对所述M个采样点的第一音频数据和所述第一缓存区中剩余的N个采样点的第一音频数据做音量的淡出处理，包括：

当所述第一缓存区中剩余的(M+N)个采样点的第一音频数据满足设定要求时，所述第一声道对所述M个采样点的第一音频数据和所述第一缓存区中剩余的N个采样点的第一音频数据做音量的淡出处理。

6.根据权利要求5所述的方法，其特征在于，所述满足设定要求为(M+N)≤(M*7/4)。

7.根据权利要求5所述的方法，其特征在于，所述做音量的淡出处理，包括：

在所述第一读数据时间与所述第一写数据时间之间的第一时间差不小于所述第一时间阈值，且所述第一缓存区中剩余的(M+N)个采样点的第一音频数据满足设定要求时，所述第一声道获取所述第一缓存区中读第一音频数据位置处的第一音频数据对应的音量值；

对于所述(M+N)个采样点的第一音频数据的音量值，从第一个采样点的第一音频数据开始至第(M+N)个采样点的第一音频数据，将所述音量值均匀递减至0。

8.根据权利要求1所述的方法，其特征在于，M的取值根据所述第一音频数据的格式和所述音频模块的硬件参数确定。

9.根据权利要求1所述的方法，其特征在于，所述第一缓存区为环形共享内存。

10.根据权利要求1所述的方法，其特征在于，所述方法还包括：

第三线程循环调用写函数，将接收到的第二音频数据写入第二缓存区，并在每次调用所述写函数将接收到的所示第二音频数据写入所述第二缓存区后，计算第二时间阈值，将所述第二时间阈值写入所述第二缓存区，将当前系统时间作为第二写数据时间写入所述第二缓存区；

所述第二线程通过与所述第三线程对应的第二声道，从所述第二缓存区中读取X个采样点的第二音频数据；其中，所述第二声道每次从所述第二缓存区中读取X个采样点的第二音频数据时，获取当前系统时间作为第二读数据时间，并在所述第二读数据时间与所述第二写数据时间之间的第二时间差不小于所述第二时间阈值时，对所述X个采样点的第二音频数据和所述第二缓存区中剩余的Y个采样点的第二音频数据做音量的淡出处理，X和Y均为正整数；

所述第二线程将淡出处理后的所述M个采样点的第一音频数据和所述N个采样点的第一音频数据，以及所述X个采样点的第二音频数据和所述Y个采样点的第二音频数据进行混音处理，得到混音数据；

所述第二线程将所述混音数据传输至音频驱动，由所述音频驱动驱动音频模块播放所述混音数据。

11.根据权利要求10所述的方法，其特征在于，所述第二缓存区为环形共享内存。

12.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在所述第一读数据时间与所述第一写数据时间之间的第一时间差小于所述第一时间阈值时，所述第一声道识别到所述第一缓存区中记录了淡出标记时，对所述M个采样点的第一音频数据和所述第一缓存区中剩余的N个采样点的第一音频数据做音量的淡出处理。

13.根据权利要求1所述的方法，其特征在于，在所述第一线程循环调用写函数之前，所述方法还包括：

在应用程序层中的第一应用程序启动之后，实例化所述第一线程、所述第一声道、所述第二线程；

所述第一线程请求共享内存分配所述第一缓冲区，并记录所述第一缓存区的地址信息；

响应作用于所述第一应用程序中对第一音频文件的播放请求，所述播放请求携带了所述第一音频文件的标识信息，所述标识信息包括所述第一音频文件的文件名和存储路径；

所述第一应用程序从所述存储路径中查找所述文件名的所述第一音频文件；

其中，所述第一线程循环调用写函数，将接收到的第一音频数据写入第一缓存区，包括：

所述第一线程循环调用所述写函数，从所述第一音频文件中读取第一音频数据，并将所述第一音频数据写入所述第一缓存区。

14.根据权利要求13所述的方法，其特征在于，所述标识信息还包括所述第一音频文件中第一音频数据的采样率；

所述第一线程循环调用所述写函数，从所述第一音频文件中读取第一音频数据，并将所述第一音频数据写入所述第一缓存区，包括：

在所述第一音频数据的采样率与所述第一声道从所述第一缓存区中读取音频数据的采样率不匹配时，对所述第一音频文件中的第一音频数据进行重采样；

所述第一线程循环调用所述写函数，从重采样后的所述第一音频文件中读取第一音频数据，并将所述第一音频数据写入所述第一缓存区。

15.一种电子设备，其特征在于，所述电子设备包括：存储器和处理器，所述存储器和所述处理器耦合；所述存储器存储有程序指令，所述程序指令由所述处理器执行时，使得所述电子设备执行如权利要求1至14任意一项所述的音频处理方法。

16.一种计算机可读存储介质，其特征在于，包括计算机程序，当所述计算机程序在电子设备上运行时，使得所述电子设备执行如权利要求1至14任意一项所述的音频处理方法。