最近处理音频的问题，所以看了一些不错的文章，整理一些有用的资料出来，有需要的可以收藏。

ALSA的框架图：

这个图可以说是我目前看到最不错的，我发现很多应用开发的，一出现解决不了的问题，或者奇怪的问题，就会怀疑内核，所以对alsa架构的理解一定会对你有帮助的。

内核有一个ringbuffer来存储应用的数据，然后再通过DMA和ADC或者DAC通信，我们在内核基础上开发ALSA应用，是有很多接口来读取、控制ALSA的接口。

ringbuff的大小，以及ringbuff的读写指针位置，以及ringbuff剩余空间大小，有对应的设备节点来读取。

除了上面的STATUS还有两个可以查看的参数

rc =snd_pcm_hw_params(handle, hw_params);

和

snd_pcm_sw_params(handle, sw_params)

这些参数的解释

period_size：每次传输的音频数据大小，字节数，如果是非阻塞播放的话，这个值越小，那每次给内核ringbuff传数据就越小，那CPU占用率就越大，当然，系统的音频延时也就越小了。　

period_count：缓之冲区period的个数。

start_threshold：从应用传输数据到内核后，缓冲区的数据超过这个值时DMA开始启动传输。如果设置的值太大，那数据量很小的时候，DMA就不启动发送数据给Codec导致音频数据播放不出来，这个值建议是越小越好。　

stop_threshold：缓冲区空闲区大于该值时，硬件停止传输。默认情况下，这个数 为整个缓冲区的大小，即整个缓冲区空了，就停止传输。但偶尔的原因导致缓冲区空， 如CPU忙，增大该值，继续播放缓冲区的历史数据，而不关闭再启动硬件传输(一般此时有明显的声音卡顿)，可以达到更好的体验。　　

silence_threshold：这个值还不是很清楚他的用途，有知道的可以留言解释下。

avail_min：缓冲区空闲区大于该值时，pcm_mmap_write()才往缓冲写数据。这个 值越大，往缓冲区写入数据的次数就越少，面临XRUN的机会就越大。

---

获取ringbuff中的缓存值

这是最近遇到的一个问题，这持续播放的时候，我使用snd_pcm_avail函数读取内核缓存的值，发现随着系统的运行，这个值就越来越小，那就说明我们系统在运行中的时候有累积的一些数据没有得到播放。

关于这个函数的解释

https://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#ga577b4d51e08d94930a05bbe73291ed2a

中文意思：

对于录音是当前可以读取的音频字节数。

对于播放是当前可以写的音频字节数，如果内核的缓存越来越小，这个值也会越来越小。

搞音频的可以看看这几个博客：

https://zhuanlan.zhihu.com/p/537562136

https://www.cnblogs.com/cslunatic/p/3677729.html