【翻译】音游开发速成：与DSP同步（作者：5argon）
【文章原载于https://exceed7.com/native-audio/rhythm-game-crash-course/dsp-sync.html，授权翻译转载，再次转载请联系原作者获取授权。】
【系列文章目录】
音游开发速成（概论）
背景音轨
游戏设计与制谱
四类音频应用程序
音频导入设置
与DSP同步【本文】
来自Bemuse作者的提示
额外内容：与dspTime同步
前文提到我们不应该与音频时间同步。精准地播放背景音轨对大多数音游来说已经足够了。但如果您确实需要与音频时间同步呢？例如或许在音游以外的游戏中，如果玩家正好在歌曲快进入副歌时到达某个特定地点，就将副歌替换为另一个史诗感更强的版本。
您希望像Time.realTimeSinceStartup一样实时地获取真正的当前音频时间。该API甚至会在连续的两行代码间改变其值，这表明它的实时性非常强。
根据我的研究，AudioSettings.dspTime和audioSource.time以一种离散的步骤更新，其更新步骤是互相分离而非连续的。如果您在同一帧中数次请求该值，其结果可能改变也可能不改变，这取决于更新步骤是否发生在两次请求间。但该值在连续的两行代码间非常有可能保持一致，这与Time.realTimeSinceStartup不同。
现在来看看本地时间。您可以请求由Native Audio（2.0版本后）所播放的音频的dspTime。不幸的是，我发现Android和iOS汇报的时间也像Unity的dspTime一样以离散的步骤更新。似乎所有的音频引擎都是这样，没有什么值是真正实时的。
不过也有一些差别：
[Android] 更新步骤仍然是离散的，但独立于Unity的dsp更新步骤（AudioSettings.dspTime和audioSource.time）。如果Unity中的这两个时间在几行代码间发生变化，Android时间不一定会改变；如果Android时间发生变化，这两个Unity时间不一定会改变。可以看到图中蓝线与红黄两线的抖动方式并不相同。
[iOS] 出人意料的是，从OpenAL获取的时间竟然与AudioSettings.dspTime和audioSource.time的更新步骤是一致的。这表明它们在内部使用的是同一套系统。如果其中一个时间不变，那么其他时间也不变。
在iOS中，您会看到黄线和蓝线经常重叠在一起。从本地获取的时间往往比从Unity的音频源请求到的时间更接近Unity的dspTime，甚至可能与Unity的dspTime相同。这可能是由于较低的延迟使音频更早开始播放，所以只有红线被延迟了。
您购买的Native Audio程序包中附带了生成上面这种图表的测试场景（只是为了好玩）。
另外，是一位Discord用户分享给我的这条推文使我发现了这个问题。这是一个很棒的发现！
在Unity中同步音乐很难办。 timeSamples和dspTime似乎都指向音频缓冲区的起点，而不是当前的播放位置。（pic.twitter.com/Ha6MDxQNuX）
— Freya Holmér（@FreyaHolmer）2017.3.26（https://twitter.com/FreyaHolmer/status/845954862403780609?ref_src=twsrc%5Etfw）
