AVAudioEngine节拍器scheduleBuffer完成回调的时序偏差问题

你遇到的BPM偏低问题，完全是当前实现逻辑的固有缺陷导致的，和AVAudioEngine本身的精度无关：

• 链式排程的空窗延迟：你当前的逻辑是等当前buffer播放完成，触发completionHandler后，再切到主队列执行下一次playClickLoop()排程。这个流程的延迟来自三部分：线程切换的系统开销、主队列的调度优先级延迟、主队列处理其他UI任务的排队延迟。由于scheduleBuffer传的at参数是nil，下一个buffer的播放时机完全取决于“buffer被加入播放队列的时间”，整个延迟会直接加到每个节拍的间隔里，最终导致实际BPM低于设定值。你实测180BPM时偏差到172.3BPM，对应每拍多了约15ms的空窗延迟，完全符合这种线程调度延迟的特征。
• UI逻辑和音频时序脱节：你在排程buffer的同时就立刻更新标签显示，但是排程本身是提前（甚至因为延迟是延后）的动作，和buffer实际播出声音的时间点没有绑定，自然会出现UI和音频不同步的问题。
• Buffer设置的误导性：你把只有26ms/1150采样的音效，强行填充静音拉长到整个节拍周期长度，虽然填充静音本身不影响音质，但是放大了链式排程的空窗问题——因为整个buffer播完才会触发回调，空窗期是从buffer最后一帧播完的瞬间开始计算，没有任何提前量。

你之前用scheduleBuffer的loop属性时时序表现好，核心原因是loop的排程动作完全在音频实时线程完成，没有跨队列的空窗延迟。我们要做的就是手动复刻这种精准排程的逻辑，同时支持不同音效切换和UI同步，核心原则是：所有音频排程必须基于绝对采样时间戳提前完成，不要等播放完成再排下一个，彻底消除空窗延迟。
具体调整点：

1. 修正Buffer初始化逻辑
   • 不要强行把音效buffer拉长到节拍周期长度。直接加载原始音效的实际长度（1150采样）到buffer1、buffer2中，保留音效本身的时长即可。
2. 改用绝对时间戳排程，代替链式回调
   • 为每一次要播放的节拍计算精准的未来播放时间点：
     • 启动时，基于播放器当前的实时渲染采样时间，计算第一个节拍的播放时间（通常提前排1024个采样点，也就是约23ms，保证排程动作完成时，播放时间还在未来）。
     • 之后每一个节拍的播放时间，就是上一个节拍的时间 + （60/BPM * 采样率）对应的采样数，全程用累计的绝对采样时间点排程，完全不依赖上一次播放完成的事件。
3. 批量提前排程，利用completionHandler做补排
   • 启动节拍器时，一次性把未来4~8拍的buffer全部按计算好的时间戳排进播放队列，保证播放器的缓冲队列里永远有提前的待播内容。
   • 当已排的buffer被播放完成触发completionHandler时，再补排后面的N拍buffer。这种模式下，completionHandler的回调延迟完全不影响已排好的内容的播放时机——哪怕回调晚了几十毫秒，只要新排的buffer的时间戳是在未来的，就会在精准的时间点播出，不会累积延迟。
4. 实现UI和音频的完全同步
   • 不要在排程动作执行的瞬间就更新UI。排程是提前动作，和实际播出时间有固定差值。
   • 每次排程一个节拍时，计算出该节拍对应的实际系统时间（把音频节点的采样时间戳转换成wall clock时间），在主队列设置一个对应时间点的定时任务，到了实际播出的瞬间再更新标签内容，就能保证UI反馈和声音完全对齐。

// 记录下一个待排程的节拍对应的绝对采样时间
private var nextScheduleSampleTime: AVAudioFramePosition = 0
private var currentBeat: Int = 0

private func scheduleUpcomingBeats(_ beatCount: Int) {
    guard engine.isRunning, player.isPlaying else { return }
    // 获取播放器当前的实时渲染时间
    guard let playerNow = player.lastRenderTime,
          let playerSampleNow = playerNow.playerTime(forNodeTime: playerNow.nodeTime) else { return }
    
    // 首次启动时初始化排程基准时间
    if nextScheduleSampleTime == 0 {
        nextScheduleSampleTime = playerSampleNow.sampleTime + 1024
    }
    
    for _ in 0..<beatCount {
        currentBeat += 1
        if currentBeat > 4 { currentBeat = 1 }
        let playBuffer = (currentBeat == 1) ? buffer1! : buffer2!
        
        // 构造带绝对采样时间的排程时间戳
        let scheduleTime = AVAudioTime(sampleTime: nextScheduleSampleTime, atRate: sampleRate)
        player.scheduleBuffer(playBuffer, at: scheduleTime, options: [], completionHandler: nil)
        
        // 计算该节拍实际播放对应的系统时间，同步UI
        let outputSeconds = Double(nextScheduleSampleTime - playerSampleNow.sampleTime) / sampleRate
        DispatchQueue.main.asyncAfter(deadline: .now() + outputSeconds) { [weak self] in
            self?.label.text = "\(self?.currentBeat ?? 0)"
        }
        
        // 累加计算下一个节拍的绝对时间
        nextScheduleSampleTime += AVAudioFramePosition(periodLengthInSamples)
    }
}

启动时的调用逻辑：

// 按钮触发启动时
player.play()
nextScheduleSampleTime = 0
currentBeat = 0
// 一次性提前排4拍
scheduleUpcomingBeats(4)
// 利用回调补排：每播完1拍，就补排1拍，保证队列永远有提前的内容
player.scheduleBuffer(AVAudioPCMBuffer(pcmFormat: buffer1.format, frameCapacity: 0), at: nil, options: [], completionHandler: { [weak self] in
    self?.scheduleUpcomingBeats(1)
})

内容的提问来源于stack exchange，提问作者McNail