前言
公司今年開始設置了創(chuàng)新獎，分享獎等各種大獎，不由得動力滿滿的，是時候拿些壓箱底來沖擊下獎項了。
正所謂，博一博，單車變摩托。
1，音頻API
安卓sdk里，播放音頻有 SoundPool，MediaPlayer， AudioTrack 三種方案。
SoundPool，明顯不適合技術(shù)選型，因為它比較適合播放短促音效，文件小的音頻。
MediaPlayer，使用頻繁的方案，自帶解碼，支持mp3，wav等音頻文件，但只支持單一音頻播放。同樣不適合。
AudioTrack，偏底層的音頻播放方案，只支持pcm文件。所以，需要將音頻文件解碼成PCM（byte[] ），再將數(shù)據(jù)讀取到固定的buffer緩存塊里，然后再寫入 AudioTrack ，就可以播放聲音。
由于前面兩個選項已被否決。那么，AudioTrack適不適合混和播放呢？暫不做確認，先看看什么是混和播放。
2，混音播放
混和播放，也就是多音軌同時播放，暫停，seekTo 等操作。
MediaPlayer 也不是不行。新建多個MediaPlayer實例，然后同時操作，該方案其實也是項目里Loop最初的實現(xiàn)方案，曲譜的實現(xiàn)方案。
雖然項目里的重點模塊-曲譜都用上該方案，說明可行性還是有的。但終究不是終極方案。
比如所有音軌播放之前，播放一段前置節(jié)拍。此時會出現(xiàn)銜接間斷的問題。
由于MediaPlayer是對AudioTrack的封裝，所以，這個方案的邏輯，其實是系統(tǒng)針對多應用同時播放聲音的方案。
所以，簡單的將MediaPlayer替換成AudioTrack，通過多個AudioTrack實例來實現(xiàn)，原理上是一模一樣的。
那還有沒有其他方案呢。
這里就不得不探討下聲音的數(shù)字化的原理：在單位時間內(nèi)對聲波進行采樣，最后量化成pcm數(shù)據(jù)。
同理，混音的原理是是：各個聲音波形的疊加，也就是pcm數(shù)據(jù)的疊加。
而安卓sdk提供的音頻API里，唯一能夠針對pcm數(shù)據(jù)進行播放的，就只有AudioTrack。
結(jié)合上述的分析，具體的方案如下圖：
所以，該方案可行？
這里拋開其他一些額外處理（比如不同采樣率的音頻混音，混音后的溢出），理論上是可行的，但其實有個致命的問題。
那就是多音軌時，jvm內(nèi)存可能會爆掉。
這筆帳是可以算清楚的，
假如采樣率為 44100HZ，位深為 16bit，聲道數(shù)為 2 的 pcm，60 秒大小應為
44100×16bit×2×60s÷8bit=10,584,000Byte=10.0936889648MB?
而 Loop 單軌最高錄制 5分鐘，即單軌大小為 50M，8軌共計 400M
對于一些低端機型，怕是要承受不來的。
但實際場景并沒有這么極限。所以，應該是可行的。
實際上，恩雅APP采用了Google Oboe的方案，比AudioTrack更加底層，更加高效以及低延遲。
但混音原理是一樣的，至于不同采樣率的音頻混音，混音后的溢出同樣是存在的，這些還未完善。
而內(nèi)存溢出方面，由于JNI 沒有內(nèi)存限制，所以比AudioTrack更加放心。實測錄制8條5分鐘的音軌，整個應用占用的將近1G，1+3機型也不會出現(xiàn)內(nèi)存溢出的問題。
至于為何一開始沒有在AudioTrack下功夫，只是項目前期已經(jīng)接入Google Oboe，也就不再考慮范圍。
所以，接下來，則是重頭戲 Oboe 的混音實現(xiàn)了。由于篇幅太長，只能下集解說了。
