Question

据我了解，音频上下文具有：

.currentTime，是下一个可调度的128样本帧缓冲区（之前的缓冲区已经发送）开始的时间
.baseLatency，是将计划的音频从WebAudio传输到操作系统所需的时间
.getOutputTimestamp().contextTime，是当前移交给操作系统的示例帧的时间戳

根据这种理解，context.getOutputTimestamp().contextTime不应小于context.currentTime - context.baseLatency。

但是！在我在快速MacBook上的Chrome中进行的测试中，它比-0.025s小得多。那是后面的1000个样本帧。

const context = new AudioContext();

// Let the audio clock settle
setTimeout(function() {
    const currentTime = context.currentTime;
    const contextTime = context.getOutputTimestamp().contextTime;
    console.assert(
        contextTime > (currentTime - context.baseLatency),
        'contextTime', contextTime,
        'currentTime', currentTime,
        'baseLatency', context.baseLatency,
        'contextTime - (currentTime - baseLatency)', contextTime - (currentTime - context.baseLatency)
    );
}, 1000);

我是关于它应该做什么的假设还是API对我来说是关于baseLatency的谎言？

Answer 1

.baseLatency基本上是WebAudio实现正常工作所需的音频样本数。它可以低至128（但不能更低），并且可以大得多（8000或更高）。对于Mac，默认值为256。此值用于消除音频时钟的任何抖动。 Mac的抖动非常低，因此256（或128）效果很好。 Linux机器的准确性往往不高，因此使用512或更高版本。（适用于Chrome。）

这不包括在webaudio和浏览器音频系统之间以及从浏览器到OS以及从OS到实际输出设备之间的任何其他缓冲。（我了解蓝牙设备有时可能会有很大的延迟。）

应该显示一个outputLatency属性，但是AFAIK尚未在任何浏览器中实现。

Answer 2

我的假设是歪曲的。 Web Audio规范在getOutputTimestamp（https://www.w3.org/TR/webaudio/#dom-audiocontext-getoutputtimestamp）部分的注释中对此进行了明确说明。

我的问题中的第三个项目符号是错误的。正如我在问题中所指出的，.getOutputTimestamp().contextTime 不是当前正在移交给音频驱动器的示例帧的时间戳。顾名思义，它是当前从音频驱动器输出的示例帧的时间戳。

@Raymond在他的答案中暗示，将此时间戳与之进行比较的正确延迟为outputLatency（截至2019年1月尚未实现）。

在网络音频中，为什么contextTime比currentTime落后baseLatency？

2 个答案: