UnderRun和OverRun

本文探讨了音频播放及录音场景中常见的Underrun与OverRun问题。详细解析了这两种现象的原因及其处理机制,包括pcm播放时AudioTrack与AudioFlinger间的交互,以及录音时上层应用与alsa buffer之间的数据流动。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

UnderRun

pcm播放的场景,alsa中snd_pcm_write()返回–EPIPE,表示alsa取不到足够的数据;

AudioTrack 写入数据的速度跟不上 AudioFlinger 读取数据的速度,使得 AudioFlinger 不能及时获取到预期的数据量,反映到现实的后果就是声音断续;这种情况的根本原因大多是应用程序不能及时写入数据或者缓冲区分配过小,AudioTrack 本身并没有错;AudioFlinger 针对这点做了容错处理:当发现 underrun 时,先陷入短时间的睡眠,不急着读取数据,让应用程序准备更多的数据。

当检测到当前写入音频数据的时间与上次出现警告的时间间隔大于预定的最大时间间隔(5秒)后,系统将判定音频播放过程出现了 underrun。然后系统会调用 usleep() 函数对当前 PlaybackThread 进行短时间阻塞,这样上层 APP 就能为 PlaybackThread 准备好更多音频数据。这个 usleep() 的时长是根据相邻 2 次写入音频数据的时间间隔实时计算出的。

OverRun

record录音的场景,alsa中snd_pcm_read()返回–EPIPE,表示alsa的buffer满了;上层app取数据取得太慢。

ALSA 的驱动也有一块专门用来存储录音数据的 buffer,上层从该 buffer 搬运数据再存储起来就能得到我们需要的录音文件。一旦驱动的 buffer 满了,就会出现 EPIPE 的错误,因为上层读录音 buffer 数据的速度慢了。

Simulink模型里的Audio Device Writer模块是用于将音频信号输出到音频设备(如扬声器)中的模块。 Audio Device Writer模块的主要功能是将输入的音频信号进行缓存处理,然后输出到指定的音频设备中。模块支持多个声道(通道)的音频信号输出,可以根据实际需求设置声道数采样率等参数。 Audio Device Writer模块的主要参数设置如下: 1. Device name:音频设备的名称,可以是系统默认设备或者用户自定义设备。 2. Sample time:音频信号的采样时间间隔,即采样周期。一般情况下,采样时间间隔需要与输入信号的采样时间间隔相同,以保证数据的同步性。 3. Number of channels:音频信号的声道数,一般为1(单声道)或2(立体声)。 4. Samples per frame:每个采样周期中的采样点数,即每帧的采样点数。采样点数越多,音频信号的精度质量就越高,但同时也会增加计算量延迟。 5. Buffer size:音频缓存的大小,即缓存中可以存储的音频数据的最大数量。缓存大小需要根据实际应用场景计算资源的限制进行设置,不能过小或过大。 6. Overrun action:缓存溢出时的处理方式,可以选择停止模拟、继续模拟、或输出错误提示信息等。 7. Underrun action:缓存欠载时的处理方式,可以选择停止模拟、继续模拟、或输出错误提示信息等。 通过合理设置Audio Device Writer模块的参数,可以实现高质量、实时的音频输出,满足不同应用场景的需求。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

sunxiaolin2016

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值