【翻譯】音游開發(fā)速成：與DSP同步（作者：5argon）
【文章原載于https://exceed7.com/native-audio/rhythm-game-crash-course/dsp-sync.html，授權翻譯轉載，再次轉載請聯(lián)系原作者獲取授權?！?/span>
【系列文章目錄】
音游開發(fā)速成（概論）
背景音軌
游戲設計與制譜
四類音頻應用程序
音頻導入設置
與DSP同步【本文】
來自Bemuse作者的提示
額外內(nèi)容：與dspTime同步
前文提到我們不應該與音頻時間同步。精準地播放背景音軌對大多數(shù)音游來說已經(jīng)足夠了。但如果您確實需要與音頻時間同步呢？例如或許在音游以外的游戲中，如果玩家正好在歌曲快進入副歌時到達某個特定地點，就將副歌替換為另一個史詩感更強的版本。
您希望像Time.realTimeSinceStartup一樣實時地獲取真正的當前音頻時間。該API甚至會在連續(xù)的兩行代碼間改變其值，這表明它的實時性非常強。
根據(jù)我的研究，AudioSettings.dspTime和audioSource.time以一種離散的步驟更新，其更新步驟是互相分離而非連續(xù)的。如果您在同一幀中數(shù)次請求該值，其結果可能改變也可能不改變，這取決于更新步驟是否發(fā)生在兩次請求間。但該值在連續(xù)的兩行代碼間非常有可能保持一致，這與Time.realTimeSinceStartup不同。
現(xiàn)在來看看本地時間。您可以請求由Native Audio（2.0版本后）所播放的音頻的dspTime。不幸的是，我發(fā)現(xiàn)Android和iOS匯報的時間也像Unity的dspTime一樣以離散的步驟更新。似乎所有的音頻引擎都是這樣，沒有什么值是真正實時的。
不過也有一些差別：
[Android] 更新步驟仍然是離散的，但獨立于Unity的dsp更新步驟（AudioSettings.dspTime和audioSource.time）。如果Unity中的這兩個時間在幾行代碼間發(fā)生變化，Android時間不一定會改變；如果Android時間發(fā)生變化，這兩個Unity時間不一定會改變?？梢钥吹綀D中藍線與紅黃兩線的抖動方式并不相同。
[iOS] 出人意料的是，從OpenAL獲取的時間竟然與AudioSettings.dspTime和audioSource.time的更新步驟是一致的。這表明它們在內(nèi)部使用的是同一套系統(tǒng)。如果其中一個時間不變，那么其他時間也不變。
在iOS中，您會看到黃線和藍線經(jīng)常重疊在一起。從本地獲取的時間往往比從Unity的音頻源請求到的時間更接近Unity的dspTime，甚至可能與Unity的dspTime相同。這可能是由于較低的延遲使音頻更早開始播放，所以只有紅線被延遲了。
您購買的Native Audio程序包中附帶了生成上面這種圖表的測試場景（只是為了好玩）。
另外，是一位Discord用戶分享給我的這條推文使我發(fā)現(xiàn)了這個問題。這是一個很棒的發(fā)現(xiàn)！
?在Unity中同步音樂很難辦。 timeSamples和dspTime似乎都指向音頻緩沖區(qū)的起點，而不是當前的播放位置。（pic.twitter.com/Ha6MDxQNuX）
— Freya Holmér（@FreyaHolmer）2017.3.26（https://twitter.com/FreyaHolmer/status/845954862403780609?ref_src=twsrc%5Etfw）
