音频筑基:算法时延分析

发布时间:2024年01月16日

音频筑基:算法时延分析

前言


音频算法中,经常遇到时延分析的问题,刚开始接触大多都比较迷惑,这里将自己对时延的学习思考梳理总结于此。

时延是啥


音频领域中,时延(delay/latency)主要指声音从源端发出,经链路传输,再到对端接收到声音,所经过的总时间延迟。一般人耳无法感知的蓝牙段链路时延是25-30ms以内。

一般来说,时延首先要分清楚计算器处理时延(依赖硬件)和算法时延(不依赖于硬件的)。这里以蓝牙链路为例,分析下传输延迟的组成:

  • 音频编解码所需缓存及处理时间,算法相关
  • 音频输入输出的硬件延迟和缓存时间,硬件相关
  • 蓝牙传输物理层和协议层及缓存时间,硬件相关
  • 蓝牙数据包重传机制,硬件与场景相关

举例分析


这里以音频编解码算法为例,看看算法维度里的时延:

  • 算法处理硬件运行时间
  • 算法处理端到端延迟时间

算法处理硬件运行时间,指跑完这个算法实际硬件所需时间,当下硬件处理水平普遍都小于编解码算法的帧长、look ahead等延迟总和,故而通常不予考虑。

算法处理端到端(E2E, end to end)延迟时间,指:1、进入编解码积攒的音频帧(Capturing)所需时间(如10ms),2、编解码低延迟频域转换所需look ahead(如2.5ms)。这两种延迟均是算法原理带来的,直接影响端到端延迟,不与硬件有关系,所以也简称为算法时延。

The look ahead delay is algorithmic only and represents a delay in audio content, and not actual processing time.

time: |-----|--------------------|----------|**********************|--------------|-------|
type:   adc,   capturing frame,    encoding,    transport/retrans,      decoding,    dac

如下图所示,硬件处理时间如adc, encoding(硬件运行), transport, retrans, decoding(硬件运行),dac。

整体过程简单理解就是音频物理信号产生,经过数模转换成数字信号,再经过编码压缩,通过网络传输/重传发送,对端接收到解码,再数模转换成模拟信号播放出来。

其中,encoding项经过算法后就会导致端到端信号偏移frame time + look ahead这么长的算法时延,硬件处理通常能在单帧时间内解码完毕,所以编解码硬件时间通常不考虑。

相关资料


  1. Introducing-Bluetooth-LE-Audio-book,link, P137, Figure 5.7
  2. Unraveling Bluetooth LE Audio,link,Table6-2. Figur 6-3
文章来源:https://blog.csdn.net/qq_17256689/article/details/135634732
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。