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

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

【技术实现步骤摘要】
一种低延迟全场景音频实现方法、装置和电子设备


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

技术介绍

[0002]在当前智能产品种类日益丰富的今天，对音频的采集并进行低延迟时间的播放，需求越来越迫切。目前市面上的该类产品的应用一般存在两个方面的缺陷：
[0003]缺陷一,不能实现全场景的音频采集及播放。
[0004]目前市面上的音频采集及回放应用，一般只能在指定的APP里面才能实现，比如K歌APP、会议APP等，用户只能在指定的APP界面，对着麦克风说话，才能听到人声，在其他的界面，就不能实时听到麦克风的人声。
[0005]例如现有的K歌系统在打开特定的K歌APP的应用界面后才能输出人声，人声采集、人声处理、与伴奏混音及播放等逻辑工作在应用层执行，一旦退出特定的K歌APP的应用界面，就无法继续输出人声，没法做到全场景的人声输出。当然，APP也能以后台服务的方式在后台进程中进行人声采集、人声处理、混音及播放，但这样做有一个缺点，目前的智能设备的操作系统一般本文档来自技高网...

【技术保护点】

【技术特征摘要】
1.一种低延迟全场景音频实现方法，其特征在于，所述方法包括：在操作系统的内核(kernel)层并行执行音频采集线程和音频播放线程；在所述音频采集线程获取第一音频数据；在所述音频播放线程播放所述第二音频数据，所述第二音频数据至少包括所述第一音频数据。2.根据权利要求1所述的低延迟全场景音频实现方法，其特征在于，所述第二音频数据包括湿声数据，在所述在操作系统的内核(kernel)层还包括：音频处理线程，在所述音频处理线程对所述第一音频数据进行音效处理及加工，获得湿声数据；所述音频采集线程、音频播放线程和/音频处理线程通过各自对应的全局的环形缓冲区来实时分享音频数据。3.根据权利要求1或2所述的低延迟全场景音频实现方法，其特征在于，所述第二音频数据包括混音数据，在所述音频处理线程执行：获取用于伴奏的第三音频数据；将所述湿声数据和所述第三音频数据进行混音，获得混音数据。4.根据权利要求3所述的低延迟全场景音频实现方法，其特征在于，所述第三音频数据为静音数据，所述静音数据是全为0的音频数据。5.根据权利要求3所述的低延迟全场景音频实现方法，其特征在于，所述获取用于伴奏的第三音频数据，包括：播放静音数据，所述静音数据是全为0的音频数据；将所述静音数据和所述第三音频数据进行混音。6.根据权利要求1所述的低延迟全场景音频实现方法，其特征在于，通过调整单次处理的音频数据的帧数降低所述音频采集线程和所述音频播放线程的延迟时间，所述音频数据包括所述第一音频数据和第二音频数据；所述调整单次处理的音频数据的帧数,包括：在存储的所述音频数据长度超过预设的长度的情况下，做部分丢弃或全部丢弃处理；在存储的所述音频数据长度小于...

【专利技术属性】
技术研发人员：陈长春，胡慧君，
申请(专利权)人：北京天籁传音数字技术有限公司，
类型：发明
国别省市：