Oboe Systrace 是否将非完整缓冲区视为欠载？
Oboe Systrace are non full buffers considered as underruns or not?
我正在使用 oboe 库来制作音乐应用程序。在那里，我通过将 PCM 浮点值写入给定指针来制作音乐。我很少听到我能听到的声音。我还使用以下双簧管 API 验证了这一点：
managedStream->getXRunCount();
文档说明如下：
* An XRun is an Underrun or an Overrun.
* During playing, an underrun will occur if the stream is not written in time
* and the system runs out of valid data.
* An underrun or overrun can cause an audible "pop" or "glitch".
我正在尝试调试问题。我从 Don 那里找到了这个 awesome tutorial。我用以下命令捕获了 10 秒的 systrace，请注意，在这 10 秒内，我听到 0 次可听见的欠载 pop/click 声音：
systrace.py --time=10 -o trace.html -a com.example.app audio sched
freq
aaRdy 调用的结果如下（蓝色方框高度显示缓冲区中有多少样本，高度越高，所需样本越多）：
这只是 aaRdy 调用的一小部分。从来没有一次我的缓冲区有 0 个样本。我检查了所有这些。在唐写的文章中，他说：
But then the buffer starts empty, first dropping to 96 frames,
then….oh dear…to zero! At zero we are guaranteed to have an audio
glitch because there’s no data in the buffer.
文章截图如下：
我的问题看文章，我可以保证，如果蓝框是空的，就是underrun。但是，在我的 systrace 中，它永远不会为空，而且我没有听到任何欠载流行点击，但 managedStream->getXRunCount(); 调用实际上返回了 12。不知道有没有欠载
蓝框的减少是否意味着即使不为0也存在欠载？
我深入研究后发现
managedStream->getXRunCount();
Returns 流整个生命周期的 XRun 次数。我认为它会 return 相对于上一次调用的值。所以显然我得到了 12，但没有欠载，因为这是来自先前欠载的会话。
但是，我希望看到有关在跟踪中有一个非完整缓冲区意味着什么的解释。
不要在这里 :)
what does it mean to have a non-full buffer in the trace.
这意味着此时音频硬件从缓冲区读取（和删除）数据的速度比您的应用写入数据的速度快。
如果您的应用使用大量 CPU 来生成音频数据，则这是一种相当正常的情况。也许系统上的某些其他进程优先于音频线程，您的应用无法足够快地生成所需数量的音频帧。
如果缓慢的写入情况持续足够长的时间以至于缓冲区被完全清空，并且音频设备在缓冲区为空时从缓冲区中读取，这只会成为一个问题。在这种情况下，您将遇到欠载运行并且 XRuns 计数器将增加。
如您所说，XRuns 计数器将在流的生命周期内记录欠载（或录制流的超载）次数。
我正在使用 oboe 库来制作音乐应用程序。在那里，我通过将 PCM 浮点值写入给定指针来制作音乐。我很少听到我能听到的声音。我还使用以下双簧管 API 验证了这一点：
managedStream->getXRunCount();
文档说明如下：
* An XRun is an Underrun or an Overrun. * During playing, an underrun will occur if the stream is not written in time * and the system runs out of valid data. * An underrun or overrun can cause an audible "pop" or "glitch".
我正在尝试调试问题。我从 Don 那里找到了这个 awesome tutorial。我用以下命令捕获了 10 秒的 systrace，请注意，在这 10 秒内，我听到 0 次可听见的欠载 pop/click 声音：
systrace.py --time=10 -o trace.html -a com.example.app audio sched freq
aaRdy 调用的结果如下（蓝色方框高度显示缓冲区中有多少样本，高度越高，所需样本越多）：
But then the buffer starts empty, first dropping to 96 frames, then….oh dear…to zero! At zero we are guaranteed to have an audio glitch because there’s no data in the buffer.
文章截图如下：
我的问题看文章，我可以保证，如果蓝框是空的，就是underrun。但是，在我的 systrace 中，它永远不会为空，而且我没有听到任何欠载流行点击，但 managedStream->getXRunCount(); 调用实际上返回了 12。不知道有没有欠载
蓝框的减少是否意味着即使不为0也存在欠载？
我深入研究后发现
managedStream->getXRunCount();
Returns 流整个生命周期的 XRun 次数。我认为它会 return 相对于上一次调用的值。所以显然我得到了 12，但没有欠载，因为这是来自先前欠载的会话。
但是，我希望看到有关在跟踪中有一个非完整缓冲区意味着什么的解释。
不要在这里 :)
what does it mean to have a non-full buffer in the trace.
这意味着此时音频硬件从缓冲区读取（和删除）数据的速度比您的应用写入数据的速度快。
如果您的应用使用大量 CPU 来生成音频数据，则这是一种相当正常的情况。也许系统上的某些其他进程优先于音频线程，您的应用无法足够快地生成所需数量的音频帧。
如果缓慢的写入情况持续足够长的时间以至于缓冲区被完全清空，并且音频设备在缓冲区为空时从缓冲区中读取，这只会成为一个问题。在这种情况下，您将遇到欠载运行并且 XRuns 计数器将增加。
如您所说，XRuns 计数器将在流的生命周期内记录欠载（或录制流的超载）次数。