iOS UDP服務器消息處理延遲太高〜35-40ms

Question

我們非常需要降低iOS上UDP監聽器的延遲。

我們正在實施RTP-MIDI的替代方案，該方案在iOS上運行，但依靠簡單的UDP服務器來接收MIDI數據。我們遇到的問題是RTP-MIDI能夠比iOS上簡單的UDP服務器快20ms左右的速度接收和處理消息。

我們寫了3個不同的代碼庫，以試圖消除代碼中的其他內容導致不可接受的延遲的可能性。最後，我們得出結論：iPAD實際接收數據包的時間與數據包實際呈現給我們的應用程序讀取的時間之間存在滯後。

我們用示波器測量了它。每次發送Note-On命令時，我們都會在發送設備的其中一個探測器上發出一個脈衝。我們把另一個探頭連接到ipad的音頻輸出。我們觸發了脈衝並測量了聽到音頻所花費的時間。由此產生的時間是一個可靠的平均45ms，最少38個，最少的情況下最多53個。

我們用RTP-MIDI（一個更詳細的協議）做了完全相同的測試，並且它快了20ms。我擁有的最佳預感是，作爲CoreMIDI的一部分，RTPMIDI可能會比我們的應用獲得更高的優先級，但只是承認這並不能幫助我們。我們真的需要弄清楚如何解決這個問題。我們希望我們的應用程序與RTPMIDI一樣快，甚至更快，我認爲這應該是理論上可行的，因爲我們的協議不會太雜亂。由於其期刊系統設計不當，我們宣佈RTPMIDI對於我們的應用程序是不可接受的。

所測試的3個代碼庫爲：

1. 從PGMidi例子這將轉發逐字經由虛擬MIDI端口上UDP接收的GarageBand等

2. 數據導出的目標C執行Objective-C源代碼由有經驗的音頻引擎開發人員編寫，內置低延遲正弦波發生器用於輸出。

3. Unity3D應用程序，基於Mono的UDP監聽器和內置的聲音字體合成器插件。

所有3種實現方式在範圍測試中顯示了相同的測量結果。

任何有關如何更快地獲得我們的消息的見解將不勝感激。在尋找答案

新的信息時：

我四處尋找答案，我發現this question這似乎表明，如果通信是TCP，而不是UDP的的iOS可能會更快速地響應。這需要一些努力來測試我們的部分，因爲我們的嵌入式系統缺乏TCP功能，只有UDP。我很好奇我是否可以保持打開TCP連接的唯一目的是保持Wifi響應。瘋狂的想法？我不知道。有沒有人試過這個？我需要這樣做盡可能實時。

Answer 1

回答我的問題在這裏：

爲了保持UDP延遲下來，事實證明，我所要做的就是確保在WiFi沒有沉默下去了超過150毫秒（左右）。目前我確切的時間要求是未知的，但是我運行的最初測試是相隔500毫秒的數據包，而且時間太長。當我每150ms將數據包速率提高到1時，UDP延遲與RTPMIDI相當，使我們使用與原始問題中描述的技術相同的技術，總滯後時間平均爲18ms左右（對比45ms）。這與我們的RTPMIDI測量值相當。