最近在看android audio部分代碼時，對getMinBufferSize有瞭一點新體會，之前的疙瘩終於解開瞭。
也要感謝ldh_123456兄弟的回復，幫助我對此進行瞭理解。
詳細的調用過程就不說瞭，簡單說一下下面幾行代碼的理解。
// Ensure that buffer depth covers at least audio hardware latency
// 下面這行代碼的功能，就是上面英文註釋。afFrameCount是硬件緩沖區的大小，單位是frame。
// 為什麼單位是frame呢，因為采樣率指的是1秒鐘有多少個采樣點，一個采樣點其實就是一個frame，其大小為：聲道數×采樣深度。
// 例如，雙聲道，格式即采樣深度為16bit的數據，其frame size為：2×2=4.
// afSampleRate是硬件播放時真正的采樣率。
// 解釋到這兒，下面這行代碼的意思基本明瞭瞭。
// afFrameCount / afSampleRate得出來是一個硬件緩沖區能播放多長時間，單位是 frame / (frame / s)，也就是秒瞭。
// afLatency是硬件要求的延遲，單位是ms，所以，afFrameCount / afSampleRate的結果為瞭與afLatency單位一致，就乘瞭個1000.
// ((1000 * afFrameCount) / afSampleRate)如果能寫成（1000×（afFrameCount / afSampleRate））就好理解多瞭。
// 這行代碼得出的結果就是為瞭滿足硬件延遲，軟件上至少要創建幾個buffer。註意這兒隻是算出來個數，還沒涉及每個buffer的size。
uint32_t minBufCount = afLatency / ((1000 * afFrameCount) / afSampleRate);
// 這行代碼的意思是軟件層至少應該有兩塊buffer
if (minBufCount < 2) minBufCount = 2;
// 上面計算出瞭buffer的個數，下面就該計算每個buffer的大小瞭。
// 每個buffer應該多大呢，應該與硬件buffer對應，這樣剛好一個軟件buffer的數據塞給一個硬件buffer。
// 這樣說的話，是不是軟件buffer的大小和硬件buffer一樣，為afFrameCount就OK瞭？
// 當然不是那麼簡單，因為中間會涉及采樣率轉換的問題，硬件的采樣率是固定的（一般如此），而播放的音樂的采樣率各種各樣，這樣就需要進行采樣率轉換。
// 軟件buffer保存的是轉換之前的數據，硬件buffer保存的是轉換後的數據。
// 為瞭保證軟件buffer與硬件buffer中數據播放時長對應，需要：(單個軟件buffersize / sampleRate) = (afFrameCount / afSampleRate)。
// 也就是單個軟件buffersize = (afFrameCount * sampleRate) / afSampleRate。
// 總的軟件buffer size(單位為frame)為：minBufCount * (afFrameCount * sampleRate) / afSampleRate。
// google寫成下面這個樣子，是不是故意迷惑人的？？？
*frameCount = (sampleRate == 0) ? afFrameCount * minBufCount :
afFrameCount * minBufCount * sampleRate / afSampleRate;
// 知道瞭以frame為單位的buffer size，又知道frame的定義，求以byte為單位的buffer size自然不是什麼難事。