问题描述
我有一个专用线程，可以通过snd_pcm_readi（）捕获来自Alsa的音频。我会定期进行简短的阅读，这意味着snd_pcm_readi（）返回的正整数小于我的缓冲区大小，而且音频流中显然有流行声音。然后我将线程优先级设置为实时，这将带来明显的好处，即短读操作要少得多，但这并不能解决。
I've got a dedicated thread that caputures audio from Alsa through snd_pcm_readi(). Periodically I get a short read, meaning snd_pcm_readi() returns a positive integer lower than my buffer size, and there's obviously a 'pop' sound in my audio stream. Then I set the thread priority to real-time and this gives a tangible benefit, far less short reads, but this doesn't solve.
现在的问题是：在开始之前在实时修补的Linux内核的坎bump道路上，我还能做些其他事情来提高性能吗？在专用线程中调用snd_pcm_readi（）是将音频从Alsa中拉出的最佳方法吗？
Now the question: before going down the bumpy road of a real-time patched Linux kernel, there's something else I can do to squeeze out some more performance? Is calling snd_pcm_readi() in a dedicated thread the best way to pull audio out of Alsa?
推荐答案
对于回放，缓冲区大小确定延迟。
For playback, the buffer size determines the latency.
对于捕获，它不会；只有周期大小可以确定在报告记录的样本可用之前必须等待多长时间。
因此，为防止溢出，请使缓冲区尽可能大（例如，在设置其他参数后调用 snd_pcm_hw_params_set_buffer_size_max（））。
For capture, it does not; only the period size determines how long you must wait until recorded samples are reported to be available.So to prevent overruns, make the buffer as large as possible (e.g., by calling snd_pcm_hw_params_set_buffer_size_max() after setting the other parameters).
这篇关于Alsa：snd_pci_readi（）和实时线程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！