CN113518258A - 一种低延迟全场景音频实现方法、装置和电子设备 - Google Patents

Abstract

本申请实施例涉及一种低延迟全场景音频实现方法、装置和电子设备，所述方法包括：在操作系统的内核层并行执行音频采集线程和音频播放线程；在所述音频采集线程获取第一音频数据；在所述音频播放线程播放所述第二音频数据，所述第二音频数据至少包括所述第一音频数据。本申请实施例提出的低延迟全场景音频实现方法在不改动硬件设备、不增加硬件成本的前提下，通过具体的软件处理方法，实现全场景的音频采集、处理及回放。只要智能设备开着机并连接着外部音频采集设备，无论在任何时候、任何界面下都能实时的采集外部音频设备的音频，处理音频，实时回放音频。本申请实施例还可以与第三方媒体音频混音，与第三方音频同时输出。

Description

一种低延迟全场景音频实现方法、装置和电子设备

技术领域

本申请实施例涉及音频处理技术领域，具体而言涉及到一种低延迟时间全场景音频的实现方法、装置及电子设备。

背景技术

在当前智能产品种类日益丰富的今天，对音频的采集并进行低延迟时间的播放，需求越来越迫切。目前市面上的该类产品的应用一般存在两个方面的缺陷：

缺陷一,不能实现全场景的音频采集及播放。

目前市面上的音频采集及回放应用，一般只能在指定的APP里面才能实现，比如K歌APP、会议APP等，用户只能在指定的APP界面，对着麦克风说话，才能听到人声，在其他的界面，就不能实时听到麦克风的人声。

例如现有的K歌系统在打开特定的K歌APP的应用界面后才能输出人声，人声采集、人声处理、与伴奏混音及播放等逻辑工作在应用层执行，一旦退出特定的K歌APP的应用界面，就无法继续输出人声，没法做到全场景的人声输出。当然，APP也能以后台服务的方式在后台进程中进行人声采集、人声处理、混音及播放，但这样做有一个缺点，目前的智能设备的操作系统一般为多任务系统，比如ANDROID、LINUX等，一旦系统当前同时运行的任务或应用过多，超过一定的阈值的时候，用户级别的后台的服务进程例如人声采集、人声处理、与伴奏混音及播放等会被操作系统杀死，导致无法继续在后台运行K歌系统的情况。由于用户级别的应用程序其优先级别为普通，所以当操作系统比较繁忙的时候，是无法及时获得CPU运行时间片的，这样会导致人声延迟的增加和不稳定。

缺陷二，从音频采集、音频的处理再到音频的播放，整个链路的整体延迟时间比较高。

目前市面上的音频采集及回放应用，在采集音频、音频回放时，直接调用智能设备现有的音频输入、音频输出接口，这些接口在设计时本身就没有考虑到音频低延迟时间这个需求，导致整个音频通路的延迟时间可能会超出60毫秒，在部分智能设备上可能整体延迟时间会达到或超过200毫秒。按照经验数据，人耳可以很明显的觉察到大于60毫秒的音频延迟时间。当音频通路的整体延迟时间大于60毫秒时，用户体验就会大打折扣，甚至无法接受。比如在K歌或打游戏的场合，对音频的低延迟时间要求就显得很迫切。

当然，也可以采用专门的硬件方案去降低整个音频通路的延迟时间，但增加或改动现有硬件设备，会额外的增加成本。

发明内容

本申请实施例的目的是在不改变现有的智能设备硬件或音频设备硬件、不增加硬件成本的前提下对现有的整个音频通路进行低延迟时间优化。为实现上述目的，本申请实施例提供了一种低延迟全场景音频实现方法、装置及电子设备。

第一方面，本申请实施例提供了一种低延迟全场景音频实现方法，所述方法包括：在操作系统的内核(kernel)层并行执行音频采集线程和音频播放线程；在所述音频采集线程获取第一音频数据；在所述音频播放线程播放所述第二音频数据，所述第二音频数据至少包括所述第一音频数据。

在一个可以实现的实施方式中，所述第二音频数据包括湿声数据，在所述在操作系统的内核(kernel)层还包括：音频处理线程，在所述音频处理线程对所述第一音频数据进行音效处理及加工，获得湿声数据；所述音频采集线程、音频播放线程和/音频处理线程通过各自对应的全局的环形缓冲区来实时存储音频数据。

在一个可以实现的实施方式中，所述第二音频数据包括混音数据，在所述音频处理线程执行：获取用于伴奏的第三音频数据；将所述湿声数据和所述第三音频数据进行混音，获得混音数据。

在一个可以实现的实施方式中，所述第三音频数据为静音数据，所述静音数据是全为0的音频数据。

在一个可以实现的实施方式中，所述获取用于伴奏的第三音频数据，包括：播放静音数据，所述静音数据是全为0的音频数据；将所述静音数据和所述第三音频数据进行混音。

在一个可以实现的实施方式中，通过调整单次处理的音频数据的帧数降低所述音频采集线程和所述音频播放线程的延迟时间，所述音频数据包括所述第一音频数据和第二音频数据；所述调整单次处理的音频数据的帧数,包括：在存储的所述音频数据长度超过预设的长度的情况下，做部分丢弃或全部丢弃处理；在存储的所述音频数据长度小于预设的最小阈值的情况下，填充一定数量的所述静音数据。

在一个可以实现的实施方式中，通过调整单次处理的音频数据的帧数降低所述音频采集线程、音频处理线程和所述音频播放线程的延迟时间，所述音频数据包括所述第一音频数据和第二音频数据；所述调整单次处理的音频数据的帧数，包括：在存储的所述音频数据长度超过预设的长度的情况下，做部分丢弃或全部丢弃处理；在存储的所述音频数据长度小于预设的最小阈值的情况下，填充一定数量的所述静音数据。

在一个可以实现的实施方式中，在小型嵌入式操作系统上，在所述小型嵌入式操作系统的内核(kernel)层并行执行音频采集任务、音频播放任务和/音频处理任务；所述音频采集任务、音频播放任务和/音频处理任务之间通过各自对应的全局的环形缓冲区来实时分享音频数据。

第二方面，一种低延迟全场景音频实现装置，用于在操作系统的内核(kernel)层并行执行音频采集线程和音频播放线程；所述装置至少包括：音频采集模块，用于在所述音频采集线程获取第一音频数据；和音频播放模块，用于在所述音频播放线程播放所述第二音频数据，所述第二音频数据至少包括所述第一音频数据。

第三方面，一种电子设备，包括：至少一个存储器，用于存储操作系统；

至少一个环形缓冲区，用于存储音频数据；和至少一个处理器，用于执行所述存储器存储的操作系统，当所述存储器存储的操作系统被运行时，在所述操作系统的内核(kernel)层执行以上任一实施方式所述的低延迟全场景音频实现的方法。

本申请实施例提供一种低延迟全场景音频实现方法、装置及电子设备,在不改动硬件设备、不增加硬件成本的前提下，通过具体的软件处理方法，实现全场景的音频采集、处理及回放。只要智能设备开着机并连接着外部音频采集设备，无论在任何时候、任何界面下都能实时的采集外部音频设备的音频，处理音频，实时回放音频。当智能设备正在播放任何第三方媒体音频的时候，本申请实施例还可以采集外部输入的设备的音频，并与第三方媒体音频进行混音，做到与任何第三方音频同时输出。

本申请实施例提供一种低延迟全场景音频实现方法、装置及电子设备,在不改变现有的音频设备硬件或智能设备硬件、不增加硬件成本的前提下还能够实现对现有的整个音频通路进行低延迟时间优化。

附图说明

为了更清楚地说明本说明书披露的多个实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书披露的多个实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1为本申请实施例提供的低延迟全场景音频实现方法的第一个场景图；

图2为本申请实施例提供的低延迟全场景音频实现方法的第二个场景图；

图3为本申请实施例提供的低延迟全场景音频实现方法的第三个场景图；

图4为本申请实施例提供的低延迟全场景音频实现方法的基本架构图；

图5为音频采集线程(或任务)的具体数据处理流程图；

图6为干声环形缓冲区数据量调控处理流程图；

图7为湿声环形缓冲区数据量调控处理流程图；

图8为wetMonitor模块流程图；

图9为dropWet模块流程图；

图10为dryWetMonitor模块流程图；

图11为dropDry模块流程图。

具体实施方式

下面通过附图和实施例，对本申请实施例的技术方案做进一步的详细描述。

首先介绍本申请实施例中的专有名词。

干声，本申请实施例提及的干声是指不带任何音效的原始音频。

湿声，本申请实施例提及的湿声是指经过音效算法处理过的音频。

混音，本申请实施例中提及的混音，是指湿声和伴奏(或音乐)的混合而生成的声音。

智能设备，本申请实施例中的提及的智能设备包括智能电视、智能机顶盒、平板电脑、个人电脑等带操作系统的硬件设备。

音频输入设备，本申请实施例中的音频输入设备，泛指一切可以实现外部音频输入的硬件设备，也可以是智能设备内部的音频输入设备，比如有线麦克风、无线麦克风、智能设备的内置麦克风、智能设备的Aux音频输入、以及可以提供音源输出的音频播放设备等，该设备的音频设备的接口可以是Aux模拟音频接口，USB数字接口，I2S数字音频接口，甚至是光纤或同轴数字接口。

第三方音频播放模块，本申请实施例中提及的第三方音频播放模块，是指运行在智能设备上的所有可以播放音频的应用软件或组件，包括智能设备本身的音视频播放器、安装在智能设备上的第三方音视频播放器、在线音视频播放器等一切可以播放音频的软件或组件。这些软件或组件可以具备音视频解码功能，并输出解码后的音频数据给扬声器进行播放。

扬声器，本申请实施例中扬声器是指智能设备自带的音频发声部分，某些智能设备可能会自带音频编解码器(CODEC)、音频功率放大器、喇叭等。其中，音频CODEC负责音频的A/D与D/A转换。本申请实施例将这些都统一到扬声器这部分，这部分并不是本申请实施例的核心部分，所以本申请实施例在以下文中一律以扬声器来概括。

本申请实施例提供的一种低延迟全场景音频实现方法，所有逻辑都运行在操作系统的底层,对应Android或linux系统的内核(kernel)层，可以直接与底层硬件打交道，人声采集、人声的音效处理、与伴奏的混音及播放等逻辑，都运行在kernel层，具有实时性强、系统调度优先级别高的特点，无论在任何情况下，都不会被操作系统杀死，而且能保证比较高的运行优先级，从而保证比较低的人声延迟时间。

Kernel为操作系统内核，操作系统内核是指大多数操作系统的核心部分。它由操作系统中用于管理存储器、文件、外设和系统资源的那些部分组成。操作系统内核通常运行进程，并提供进程间的通信。

本申请实施例提供的一种低延迟全场景音频实现方法都是在底层(操作系统的kernel层)实现的,下面分别从全场景音频采集及播放的实现及全场景音频的低延迟时间优化两个方面来阐述。其中，全场景音频采集及播放的实现根据有/没有第三方音频播放的情景又分为两种实现方式。详见下文。

图1为本申请实施例提供的低延迟全场景音频实现方法的第一个场景图，在该场景中没有第三方音频播放。所谓没有第三方音频播放，是指智能设备当前没有播放音频，并且也没有第三方应用播放音频。

如图1所示，在没有第三方音频播放的场景下，音频输入设备的输入音频依次经过音频采集模块、音频处理模块和音频播放模块的处理后由扬声器向外播放。其中的音频采集模块、音频处理模块、音频播放模块并不是硬件，而是运行在智能设备上的程序代码。

其中，音频采集模块实时采集音频输入设备的音频数据，并将该音频数据存入干声的环形缓冲区。将该音频数据记为第一音频数据或干声数据。

本申请实施例中的音频采集模块默认采集的是数字音频信号。如果音频输入设备的接口是Aux模拟音频输入，则需要在音频采集模块与音频输入设备之间增加模拟音频转数字音频的音频ADC转换模块。如果音频输入设备的接口为光纤输入，则需要在音频采集模块与音频输入设备之间增加音频光纤接收器。

音频处理模块从干声的环形缓冲区中读取干声数据进行一系列的音效处理及加工，根据应用场景的需要，可以有混响、回声、均衡、消噪、防啸叫等一些列算法的任意组合，经这些算法处理加工好的湿声数据，实时存入湿声环形缓冲区。

音频播放模块负责读取音频数据进行实时播放，推动扬声器发声。如果存在音频处理模块，则读取湿声的环形缓冲区的湿声数据进行播放，否则读取干声缓冲区的干声数据进行播放。

音频处理模块为非必要的模块，在一个可以实现的实施方式中，音频采集模块实时采集音频输入设备的音频数据，并将数据存入干声的环形缓冲区后，音频播放模块直接读取干声的环形缓冲区的干声数据进行实时播放，推动扬声器发声。

将音频播放模块播放的音频数据记为第二音频数据，第二音频数据可以为第一音频数据(干声数据)或湿声数据。

为了保证系统的高效率及音频的低延迟时间，上述三大模块在宏观上为并发运行，表现在计算机程序上为独立的线程，如果在小型嵌入式操作系统上则为任务，线程或任务之间通过全局的各自的环形缓冲区来实时分享音频数据。

图2为申请实施例提供的低延迟全场景音频实现方法的第二个场景图，在该场景中存在第三方音频播放。所谓第三方音频播放是指智能设备当前正在播放音频，或运行在智能设备上的第三方音频播放模块或第三方应用软件正在播放音频。

如图2所示，在存在第三方音频播放的场景下，音频输入设备输入的第一音频(干声)经过音频采集模块、音频处理模块的处理后，与媒体音频获取模块获取的音频数据流一起送入音频混音模块进行混音，获得混音数据，此时混音数据作为第二音频数据，再经由音频播放模块的处理后由扬声器向外播放。其中的音频采集模块、音频处理模块、媒体音频获取模块、音频混音模块、音频播放模块，并不是硬件，而是运行在智能设备上的程序代码。

在一个可以实现的实施方式中，音频采集模块实时收集音频输入设备的第一音频数据，并保持到干声的环形缓冲区。

可选的，音频处理模块从干声的环形缓冲区中读取第一音频数据并进行一系列的音效处理及加工，根据应用场景的需要，可以有混响、回声、均衡、消噪、防啸叫等一些列算法的任意组合，经这些算法处理加工好的湿声数据，实时存入湿声环形缓冲区。

媒体音频获取模块截获第三方音频模块播放的音频数据流，并存入伴奏的环形缓冲区。将第三方音频模块播放的音频数据流记为第三音频数据,用于伴奏。

音频混音模块从伴奏的环形缓冲区读取第三音频数据作为伴奏数据，同时读取干声的缓冲区的干声数据，将这两组数据进行软件混音后的混音数据，送到音频播放模进行实时播放，从而驱动扬声器发声。

可选地，音频混音模块从伴奏的环形缓冲区读取第三音频数据作为伴奏数据，同时读取湿声的缓冲区的湿声数据，将这两组数据进行软件混音后的混音数据，送到音频播放模进行实时播放，从而驱动扬声器发声。

为了保证系统的高效率及音频的低延迟时间，上述音频采集模块、音频处理模块、音频混音模块和音频播放模块，在宏观上为并发运行，表现在计算机程序上为独立的线程，如果在小型嵌入式操作系统上则为任务，线程或任务之间通过全局的各种环形缓冲区来实时分享音频数据。

图3为申请实施例提供的低延迟全场景音频实现方法的第三个场景图，第三个场景为全场景，即不需要区分是否存在第三方音频播放的场景。如图3所示，与图2所示的场景相比，增加了静音播放模块和系统音频服务模块，从而实现在低延迟时间全场景音频播放时不需要区分是否存在第三方音频播放的场景。该实施例中各种模块除音频输入设备及扬声器部分以外，都是运行在智能设备上的程序代码。

其中，系统音频服务模块是指系统的音频播放中间件，一般为智能设备的操作系统的音频服务组件，在系统的音频架构中，一般处于中间层，即应用层的下面，音频驱动层的上面，比如Android系统中的AudioFlinger。该模块用于重采样、多应用混音等功能。

在本申请实施例提供的低延迟全场景音频实现方法的实现中，所用的智能设备的操作系统本身能支持多个应用同时播放音频，即系统音频服务模块支持多个应用同时播放的音频进行混音得到多路音频混音数据流。

静音播放模块负责播放静音数据，即播放的音频数据全为0。当系统没有任何第三方音频播放模块播放第三音频数据时，用静音播放模块播放全为0的静音数据作为第三音频数据，来维持音频播放通道一直为工作状态，且不会让用户听到任何音频。

当第三方音频播放模块正在播放第三音频数据时，静音播放模块可以继续工作，也可以停止工作，即在任意时刻，至少要保持一路音频正在播放。如果第三方音频播放模块正在播放第三音频数据时，此时静音播放模块处于工作状态，则系统音频服务模块会将静音数据和第三方音频播放模块正在播放第三音频数据的数据流进行混音，混音后获得的多路音频混音数据流仍为第三音频数据的数据流。

在一个可以实现的实施方式中，音频采集模块实时收集音频输入设备的第一音频数据，并保持到干声的环形缓冲区。

可选的，音频处理模块从干声的环形缓冲区中读取第一音频数据并进行一系列的音效处理及加工，根据应用场景的需要，可以有混响、回声、均衡、消噪、防啸叫等一些列算法的任意组合，经这些算法处理加工好的第一音频湿声数据，实时存入湿声环形缓冲区。

媒体音频获取模块从系统音频服务模块截获多路音频混音数据流,即第三音频数据的数据流，并存入伴奏的环形缓冲区。

当音频处理模块存在时，音频混音模块从湿声的环形缓冲区中读取湿声数据，当音频处理模块不存在时，音频混音模块从干声的环形缓冲区中读取干声第一音频数据，同时从伴奏的环形缓冲区读取作为伴奏数据的第三音频数据，将这两组音频数据进行混音处理形成混音数据流，即混音数据，送入到音频播放模块进行实时播放，从而驱动扬声器发声。

为了保证系统的高效率及音频的低延迟时间，上述音频采集模块、音频处理模块、音频混音模块和音频播放模块，在宏观上为并发运行，表现在计算机程序上为独立的线程，如果在小型嵌入式操作系统上则为任务，线程或任务之间通过全局的各种环形缓冲区来实时分享音频数据。

上述全场景的音频采集及播放的具体实现方法，可以编写成用户层服务程序，在智能设备的用户层开机自动后台运行，也可以将上述方法写成底层驱动，开机自动运行。这样就可以保证在任何场景，任何界面下都能实现音频的采集及实时播放，不再依赖具体的某个应用，真正做到全场景音频采集及发声。

本申请实施例提供的低延迟全场景音频实现方法对全场景音频进行的延迟时间优化，通过全局的环形缓冲区及多线程(或多任务)的并发运行，以及对各个环形缓冲区数据的流量控制的方式，对于上文中的各个实施例，其优化方法及手段是类似的，为了避免累赘，我们就不一一的做详细的展开。

本申请实施例提出的低延迟全场景音频实现方法在不改造现有音频输入设备及智能设备硬件的前提下，通过一些列的软件方法，对音频播放通路的延迟时间进行优化，从而使整个音频通路的延迟时间稳定的降低到60毫秒以内甚至更低。

图4为低延迟全场景音频实现方法的基本架构图。如图4所示，该基本架构图包括音频采集线程、音频处理线程和播放线程，可以以生产、加工、消费的模型来理解该基本框架的三个线程。

音频采集线程类似生产环节。音频采集模块类似于生产者，它的上游为从外部音频输入的音频数据，音频采集模块将采集到的第一音频数据(干声数据)输入干声环形缓冲区，干声环形缓冲区类似于生产者半成品仓库。

音频处理线程类似加工环节。音频处理模块(类似加工者)，从干声环形缓冲区(类似于生产者半成品仓库)中读取第一音频数据(取得数据)，并进行音频处理(加工)，并将处理后的第一音频湿声数据产品放入湿声的环形缓冲区(类似成品仓库)。

播放线程类似消费环节。音频播放模块(类似消费者)，从湿声缓冲区(类似于成品仓库)读取湿声(取走产品)放入音频硬件缓冲区，然后将湿声进行实时播放，驱动扬声器发声。音频采集线程、音频处理线程和播放线程各自独立运行，只要保证干声环形缓冲区有足够的干声数据，湿声环形缓冲区有足够的湿声数据，三个线程都无需相互等待，并发运行。

上述过程类似于生产环节、加工环节、消费环节各自独立运行，只要保证各自的仓库中有足够的半成品或成品，三个环节除第一批产品需要等待以外，其他时间都不用相互等待。

本申请实施例提供的低延迟全场景音频实现方法还可以进行各环节音频延迟时间的优化及控制。

需要理解的是，音频延迟时间的累积，主要源于各个环节中音频数据缓冲区中的数据大小，而程序又是运行在智能设备的处理器上的，程序设计的原则就是尽量保证智能设备的处理器能在指定时间内，完成所有的处理工作，而且上述三个环节的最大处理时间，不能超过音频时间片的最大时间。

在上述三个环节中，最耗时的环节为音频处理模块(类似于加工环节)，因为这个模块里面有各种音频处理运算，会消耗一定的处理器时间。为了尽量减少音频的延迟时间，可以将每个模块中最小的音频数据帧数设定尽可能减小，但也不能太小，具体大小需要根据实际处理器的情况做调整，否则线程频繁上下文切换，导致处理器运行效率降低。

示例性地，最小的音频数据帧数可以定为128帧。即当各个环形缓冲区的数据超过128帧时进行音频处理线程，否则将时间片让给其他线程或任务。假设系统的音频采样率为48KHz,那么128帧的音频持续时间为：128帧/48000帧每秒＝2.6毫秒，为了保证音频流的连续性，以上每个模块的最大处理时间不能超过2.6毫秒，否则数据就会断流。可是，在实时播放过程中可能会产生爆音或断音，在这种情况下，则需要尽可能的优化音频处理模块里面的处理算法，保证最大的处理时间不要超过2.6毫秒，尽量控制在2毫秒甚至更短。这是因为处理器一般是多任务系统，如果某个线程或任务占用了太多的处理器时间，那么处理器的负担会比较重，会影响系统其他功能的正常运行。

其中，图4中的音频采集线程是不受这个128帧的影响的，即只要外部音频设备有数据到来，就会立即读取数据写入干声缓冲区，而不是等到满128帧才去做读写的。

对整个音频通路延迟时间的估算为：

T＝T1+T2+T3+T4+T5 (1)

公式1中，T为音频总延迟时间，T1为外部音频设备的延迟时间，T2为干声环形缓冲区的延迟时间，T3为湿声环形缓冲区延迟时间，T4为音频硬件缓冲区延迟时间，T5为第一笔128帧音频数据延迟时间。

由于程序是以多线程的方式并发运行在智能设备的处理器上的，智能设备的系统一般是多任务的操作系统，同时还运行着许多其他的程序，由于系统任务调度的原因，分给各个任务及线程的时间片不是固定的，所以不能保证以上的三个线程能被及时得到运行，导致以上各个环形缓冲区里面都累积有一定的音频数据，所以会产生一些音频延迟时间。所以需要将以上三个线程的优先级适当的调高，保证三个线程被操作系统优先调度。

尽管如此，还是避免不了一些抖动。

例如，外部音频设备的延迟时间T1是由外部音频输入设备里累积的音频数据长度决定的，如果音频采集线程没有从外部音频输入设备及时的读走音频数据，那么这个音频数据就会在外部音频设备的数据缓冲区累积；同理，如果音频处理线程没有及时读取干声环形缓冲区的干声数据并进行处理，那么干声数据就会累积，导致干声环形缓冲区的延迟时间T2增大；如果播放线程没有及时读取湿声环形缓冲区里面的湿声数据，那么湿声数据就会累积，从而导致湿声环形缓冲区延迟时间T3增大。音频硬件缓冲区延迟时间T4是智能设备的音频硬件缓冲区造成的延迟时间，第一笔128帧音频数据延迟时间T5是固定的，其延迟时间即为128帧/48000帧每秒＝2.6毫秒。

本申请实施例提供的低延迟全场景音频实现方法可以降低和控制整体延迟时间。

首先尽可能降低每个模块单次处理的音频数据的帧数，这里的音频数据包括所述第一音频数据和第二音频数据。

由上文的陈述所知，系统的整体延迟时间由五部分组成，每部分延迟时间的基数和每个模块中单次处理的音频帧数有关。示例性地，为了尽可能的减少这个音频帧数，同时不会导致处理器频繁的切换线程上下文，可以将这各帧数暂定为128帧。

依照整体延迟时间计算公式，如果各环节中的数据仅仅有一笔即128帧，假设音频采样率为48KHz，T1取值为处理外部音频输入设备里累积的128帧数据的时间，T2取值为处理干声环形缓冲区里累积的128帧数据的时间，T3取值为处理湿声环形缓冲区里累积的128帧数据的时间，T4取值为处理音频硬件缓冲区累积的128帧数据的时间，T5取值为固定的，处理128帧数据的时间，音频总延迟时间T为：

T＝T1+T2+T3+T4+T5＝2.66*5＝13.3毫秒。

即以上13.3毫秒为本申请实施例的最理想化的、最低的音频总延迟时间时间。

但是由于智能设备的操作系统的多任务特性，每个任务或线程分到的处理器时间片是不稳定的、抖动的，这样会导致以上每个模块都会累积音频数据量，从而导致音频延迟时间的累积。

在一个可以实现的方式中，在单次处理帧数已经固定的情况下，要降低整体延迟时间，可以控制T2、T3、T4的延迟时间，即实时调控干声环形缓冲区、湿声环形缓冲区、音频硬件缓冲区中的音频数据量。

其次，本申请实施例提供的低延迟全场景音频实现方法还可以采用音频延迟时间的动态调控策略对环形缓冲区音频延迟时间进行动态调控。

图5为音频采集线程(或任务)的具体数据处理流程图。干声的环形缓冲区不可设置过小，否则当处理器繁忙的时候，缓冲区容易频繁溢出而产生断音、爆音，示例性地，可以设定干声的环形缓冲区最多可以存储的音频数据量为16384帧，假设采样率为48KHz，那么处理干声环形缓冲区里累积的16384帧数据的延迟时间时间T2为：16384帧/48000帧每秒＝341毫秒。如图5所示,包括步骤S501-S503。

S501,读取输入的第一音频数据。示例性地，可以不受最小处理帧(128帧)的限制，只要检测到音频输入设备有第一音频数据，则立即读取第一音频数据。

S502,判断干声的环形缓冲区能否放得下这笔数据，如果能放下，执行S503，否则，直接将这笔数据丢弃。

S503，将数据写入到干声的环形缓冲区。

图6为湿声环形缓冲区数据量调控处理流程图。在其中在干声环形缓冲区数据量调控(以下简称dropDry)的步骤中，当干声环形缓冲区的剩余数据超过预设长度时，做部分丢弃或全部丢弃处理。后面将会详细介绍。在湿声数据量监控(以下简称wetMonitor)的步骤中,监视整个音频通路的整体延迟时间，并为后需的dropWet的数据丢弃做决策。dropWet的数据丢弃决策后面会在图7中详细介绍。

为了避免湿声环形缓冲区的数据溢出，可以将这个缓冲区的容量设置得足够大，示例性地，湿声环形缓冲区存储的音频数据量可以设定为16384帧，假设采样率为48KHz,那么处理湿声环形缓冲区里累积的16384帧数据的延迟时间时间T3为16384帧/48000帧每秒＝341毫秒。

如图6所示，干声环形缓冲区数据量调控处理流程执行步骤S601-S607。

S601,等待干声环形缓冲区数据帧满128帧。

S602,判断干声环形缓冲区数据帧是否达到或超过128帧；如果不满128帧，返回S601；如果达到或超过128帧，则执行S603。

S603,从干声环形缓冲区读取128帧干声数据。

S604,进行干声环形缓冲区数据量调控(以下简称dropDry)，当干声环形缓冲区的剩余数据超过预设长度时，做部分丢弃或全部丢弃处理。

S605,对128帧干声数据做音效处理，得到湿声数据。

S606,将处理好的湿声数据存入湿声环形缓冲区。

S607,进行湿声数据监控，监视整个音频通路的整体延迟时间，并为后序的dropWet的数据丢弃做决策。

图7为湿声环形缓冲区数据量调控处理流程图。其中的湿声环形缓冲区数据量调控(以下简称dropWet)，主要功能是：当湿声环形缓冲区的剩余数据超过预设长度时，做部分丢弃或全部丢弃处理。干声、湿声数据量监控(以下简称dryWetMonitor),用来监视整个音频通路的整体延迟时间，并为dropDry、dropWet的数据丢弃做决策。后面会详细介绍

如图7所示，湿声环形缓冲区数据量调控处理流程执行步骤S701-S707。

S701,等待湿声环形缓冲区数据帧满128帧。

S702,判断湿声环形缓冲区数据帧是否达到或超过128帧；如果不满128帧，返回S701；如果达到或超过128帧，则执行S703。

S703,从湿声环形缓冲区读取128帧湿声数据。

S704,进行湿声环形缓冲区数据量调控(以下简称dropWet)，当湿声环形缓冲区的剩余数据超过预设长度时，做部分丢弃或全部丢弃处理。

S705,将128帧湿声数据输出到音频播放模块。

S706,音频播放模块将湿声数据转换为模拟音频信号(第二湿声音频信号)，推动扬声器发声。

S707,进行干声、湿声数据监控，监视整个音频通路的整体延迟时间，并为dropDry、dropWet的数据丢弃做决策。

图8为wetMonitor模块流程图。wetMonitor模块在音频处理线程中调用，用来监视整个音频通路的整体延迟时间，并为dropWet模块的数据丢弃做决策。如图8所示，wetMonitor模块流程执行以下步骤S801-S805。

S801，计算出各级缓冲区的数据总量，数据总量就决定了整个音频通路总延迟时间的大小。

各级缓冲区数据总量＝干声环形缓冲区数据帧长度+湿声环形缓冲区数据帧长度+音频硬件缓冲区数据长度。

最小阈值为事先设定好的最小阈值，这个阈值可以根据实际情况做调整，假设我们这里设定为最小768帧(128*6)，假设采样率为48KHz,则整个音频通路最小延迟时间时间为：768帧/48000帧每秒＝16毫秒。

S802，当各级缓冲区数据总量持续3秒小于768帧，表示各级缓冲区的总数据量偏少，为了保证音频播放持续而不产生断音，执行S803，否则执行S804。

S803，向湿声缓冲区里面填充一定数量的静音数据(填充一定长度的数据0)，比如填充1024帧的静音数据。

S804，判断当各级缓冲区总数据量持续3秒是否大于最大阈值，如果判断结果为“是”表示整体延迟时间在增大，则执行S805。

最大阈值为事先设定好的阈值，这个阈值可以根据实际情况做调整的，示例性地，可以设定最大阈值为2560帧(128*20)，在48KHz采样率下的延迟时间时间为53.3毫秒。

S805，进行调控，设置紧急丢弃标志wetEmergDrop_f，令wetEmergDrop_f＝1。这个标志将在dropWet模块中进行判断并处理，以便将人声延迟时间降下来。

在图8中的wetEmergDrop_f湿声紧急丢弃标志，是在wetMonitor模块中置1的，此标志为1表示音频通道的整体延迟时间持续3秒超过了53.3毫秒，需要启动比较严厉的数据调控措施。

图9为dropWet模块流程图。dropWet模块在音频播放线程中调用，主要功能为调控湿声环形缓冲区数据的长度，从而保证整个音频通道保持较低的延迟时间。

最大硬件缓冲区阈值是指音频硬件缓冲区最大的允许数据长度，这个值是根据实际情况预先设定的。示例性地，可以设定为2048帧(128*16)，即48KHz采样率时，则硬件缓冲区的音频延迟时间为T4为：2048帧/48000帧每秒＝42.6毫秒。

最大湿声阈值指湿声环形缓冲区的最大允许数据长度，这个值是根据实际情况预先设定的，我们这里暂时设定为512帧(128*4)，即48KHz采用率时，对应的延迟时间时间T3为10.6毫秒。

如图9所示，dropWet模块流程执行以下步骤S901-S908。

S901，判断wetEmergDrop_f是否等于1，如果等于1，则表示需要紧急调控湿声环形缓冲区数据，执行S902。如果wetEmergDrop_f为0，则表示非紧急调控，择执行S905。

S902，继续判断当时音频硬件缓冲区的延迟时间是否瞬间超过了最大硬件缓冲区阈值，例如42.6毫秒，如果是，表示系统整体延迟时间已经到了无法容忍的地步，执行S903。如果当时音频硬件缓冲区的延迟时间没有超过42.6毫秒，则执行S904。

S903，将湿声缓冲区的全部数据丢弃，执行S908。

S904，保留湿声缓冲区最近256帧的湿声数据，剩余的湿声数据全部丢弃，执行S908。

S905，查询湿声环形缓冲区里面的剩余数据长度。

S906，判断持续8次剩余长度是否大于最大湿声阈值；如果最近持续8次剩余长度大于最大湿声阈值，例如512帧(湿声延迟时间10.6毫秒)，则执行S907；否则，不做任何丢弃处理。

S907，仅保留最近的256帧湿声数据，剩下的湿声数据做丢弃处理，结束。

S908，并令wetEmergDrop_f＝0，结束。

图10为dryWetMonitor模块流程图。dryWetMonitor模块在音频播放线程里面调用，用来监视整个音频通路的整体延迟时间，并为dropWet、dropDry模块的数据丢弃做决策。

在dryWetMonitor模块中有两个预设的阈值，一个预设的阈值为最小硬件阈值，示例性地可以设定为256帧，在48KHz采样率下延迟时间时间为5.3毫秒；另一个预设的阈值为各级缓冲区的总数据量最大阈值，简称最大阈值，示例性地可以设定为2560帧，在48KHz采样率下延迟时间时间为为53.3毫秒。

这两个预设的阈值可以根据实际情况和延迟时间要求进行调整。

各级缓冲区数据总量＝干声环形缓冲区数据帧长度+湿声环形缓冲区数据帧长度+音频硬件缓冲区数据长度。

如图10所示，dryWetMonitor模块流程执行以下步骤S1001-S1006。

S1001，查询音频硬件缓冲区可用数据量。

S1002，判断读取音频硬件缓冲区持续1秒获得的可用数据长度是否小于最小硬件阈值。如果读取音频硬件缓冲区持续1秒获得的可用数据长度均小于设定的最小硬件阈值，例如256帧，则执行S1003；如果硬件缓冲区当前数据量不小于最小硬件阈值，例如256帧，则执行S1004。

S1003，为了保证音频硬件不因为缺乏数据而断音，向音频硬件缓冲区填充一定数量的静音数据，保证音频硬件缓冲区的剩余数据量达到一定长度，例如超过1024帧，结束。

可选地，也可以保留一定的裕量，但为了保持音频的低延迟时间，不要一次填充过多。

S1004，继续计算各级缓冲区的总数据量。

S1005，判断读取各级缓冲区数据持续3秒，获得各级缓冲区数据总量如果大于最大阈值，例如2560帧，表示整体延迟时间在增大，必须进行调控，为了将人声延迟时间降下来，则执行S1006。

S1006，设置湿声紧急丢弃标志wetEmergDrop_f，令wetEmergDrop_f＝1，这个标志将在dropWet模块中进行判断并处理，同时令干声紧急丢弃标志dryEmergDrop_f＝1，这个标志将在dropDry模块中进行判断并处理，结束。

其中的dryEmergDrop_f为干声紧急丢弃标志，是在dryWetMonitor模块中置1的，此标志为1表示音频通道的整体延迟时间持续3秒超过了53.3毫秒，需要启动比较严厉的数据调控措施。

图11为dropDry模块流程图。dropDry模块在音频处理线程中调用，主要功能为调控干声环形缓冲区数据的长度，从而保证整个音频通道保持较低的延迟时间。

dropDry模块和droWet模块在原理上基本类似，在代码编程上可以合并成同一个模块，传入不同的参数，以区分干声还是湿声即可。

DropDry模块的流程说明请参考dropWet模块的流程说明，如图11所示，只是将湿声换成干声即可，在此不再赘述。

本申请的实施例提供了一种电子设备，包括至少一个存储器，用于存储操作系统；至少一个环形缓冲区，用于存储音频数据；和至少一个处理器，用于执行存储器存储的操作系统，当存储器存储的操作系统被执行时，在操作系统的内核(kernel)层执行上述任一实施例低延迟全场景音频实现的方法。

本申请的实施例提供了一种存储介质，存储介质中存储有操作系统，当操作系统在电子设备上运行时，使得操作系统的内核(kernel)层执行上述任一实施例的低延迟全场景音频实现的方法。

本申请的实施例提供了一种包含指令的程序产品，当指令在处理器上运行时，使得处理器执行上述任一实施例的低延迟全场景音频实现的方法。

本领域普通技术人员应该还可以进一步意识到，结合本申请实施例中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执轨道，取决于技术方案的特定应用和设计约束条件。本领域普通技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

结合本申请实施例中所公开的实施例描述的方法或算法的步骤可以用硬件、处理器执轨道的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

以上所述的具体实施方式，对本申请实施例的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本申请实施例的具体实施方式而已，并不用于限定本申请实施例的保护范围，凡在本申请实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请实施例的保护范围之内。

Claims (10)

1.一种低延迟全场景音频实现方法，其特征在于，所述方法包括：在操作系统的内核(kernel)层并行执行音频采集线程和音频播放线程；

在所述音频采集线程获取第一音频数据；

在所述音频播放线程播放所述第二音频数据，所述第二音频数据至少包括所述第一音频数据。

2.根据权利要求1所述的低延迟全场景音频实现方法，其特征在于，所述第二音频数据包括湿声数据，在所述在操作系统的内核(kernel)层还包括：

音频处理线程，在所述音频处理线程对所述第一音频数据进行音效处理及加工，获得湿声数据；

所述音频采集线程、音频播放线程和/音频处理线程通过各自对应的全局的环形缓冲区来实时分享音频数据。

3.根据权利要求1或2所述的低延迟全场景音频实现方法，其特征在于，所述第二音频数据包括混音数据，在所述音频处理线程执行：

获取用于伴奏的第三音频数据；

将所述湿声数据和所述第三音频数据进行混音，获得混音数据。

4.根据权利要求3所述的低延迟全场景音频实现方法，其特征在于，所述第三音频数据为静音数据，所述静音数据是全为0的音频数据。

5.根据权利要求3所述的低延迟全场景音频实现方法，其特征在于，所述获取用于伴奏的第三音频数据，包括：

播放静音数据，所述静音数据是全为0的音频数据；

将所述静音数据和所述第三音频数据进行混音。

6.根据权利要求1所述的低延迟全场景音频实现方法，其特征在于，通过调整单次处理的音频数据的帧数降低所述音频采集线程和所述音频播放线程的延迟时间，所述音频数据包括所述第一音频数据和第二音频数据；

所述调整单次处理的音频数据的帧数,包括：

在存储的所述音频数据长度超过预设的长度的情况下，做部分丢弃或全部丢弃处理；在存储的所述音频数据长度小于预设的最小阈值的情况下，填充一定数量的所述静音数据。

7.根据权利要求2-4之一所述的低延迟全场景音频实现方法，其特征在于，通过调整单次处理的音频数据的帧数降低所述音频采集线程、音频处理线程和所述音频播放线程的延迟时间，所述音频数据包括所述第一音频数据和第二音频数据；

所述调整单次处理的音频数据的帧数,包括：

在存储的所述音频数据长度超过预设的长度的情况下，做部分丢弃或全部丢弃处理；在存储的所述音频数据长度小于预设的最小阈值的情况下，填充一定数量的所述静音数据。

8.根据权利要求1所述的低延迟全场景音频实现方法，其特征在于，在小型嵌入式操作系统上，在所述小型嵌入式操作系统的内核(kernel)层并行执行音频采集任务、音频播放任务和/音频处理任务；

所述音频采集任务、音频播放任务和/音频处理任务之间通过各自对应的全局的环形缓冲区来实时分享音频数据。

9.一种低延迟全场景音频实现装置，用于在操作系统的内核(kernel)层并行执行音频采集线程和音频播放线程；其特征在于，所述装置至少包括：

音频采集模块，用于在所述音频采集线程获取第一音频数据；和

音频播放模块，用于在所述音频播放线程播放所述第二音频数据，所述第二音频数据至少包括所述第一音频数据。

10.一种电子设备，其特征在于，包括：

至少一个存储器，用于存储操作系统；

至少一个环形缓冲区，用于存储音频数据；和

至少一个处理器，用于执行所述存储器存储的操作系统，当所述存储器存储的操作系统被运行时，在所述操作系统的内核(kernel)层执行如权利要求1-8任一所述低延迟全场景音频实现的方法。

Images