我們有一個應用程序，使用低級OpenSL ES編寫的移動音頻客戶端來實現麥克風的低延遲輸入。比我們發送封裝在UDP數據報中的10ms幀到服務器。Android OpenSL ES晶振頻率
在服務器我們正在做一些後處理是curucially依賴AAN假設從移動客戶端幀進來固定間隔（10ms的每幀例如），所以我們可以將它們對齊。
看來，手機內部的晶體頻率可以改變很多東西，因爲這一點，我們正在上幾分鐘後beggining但不良對位精確的對準。
我知道，ALSA在Linux上可以告訴你，晶體的精確頻率 - 這樣你就可以糾正在此基礎上的計數。不幸的是，我不知道如何在Android中獲取這些信息。
THX的幫助
你所面臨的問題的實質是，你有一個ADC，並與不同的本地振盪器獨立的系統一個DAC。你估計你的數據包是針對第三個（也可能是第四個）CPU時鐘。
正確的解決這個問題是某種clock recovery算法。爲了做到這一點，你需要一些精確的時間戳（例如精確到位）傳輸數據包，然後使用PLL來驅動接收器採樣時鐘的時鐘速率。這正是IEEE1394音頻和MPEG2傳輸流使用的方法。
由於可能無法做到上述任何一種情況，因此您的方法很可能需要定期刪除或重複採樣（或者甚至是整個數據包），以防止接收緩衝區不足或過度流動。
USB音頻也有類似的缺乏時鐘恢復的硬件支持，以及使用方法也可能適用於您的情況。
依託網絡數據包的發送和接收定時是一種可怕的想法。交付時間的抖動非常可怕 - 特別是在Wifi或手機連接的情況下。你會被建議使用不依賴於它在所有，而是做既IEEE1394音頻和MPEG 2個TS做，這就是使用其中的數據以恆定的速率消耗模型FIFO解耦消費音頻數據傳輸並以不可靠的時機傳遞給它。
至於ALSA，所有它可以做（除非如果有一個準確的外部定時參考）是測量音頻接口的採樣時鐘和CPU時鐘之間的漂移。這不會產生任何事物的「確切頻率」，因爲這兩個振盪器都可能是準確的，並且兩者都可能隨溫度而變化。