我们迫切需要降低 iOS 上 UDP 侦听器的延迟。
我们正在实现一种在iOS上运行的RTP-MIDI的替代方案，但依赖于简单的UDP服务器来接收MIDI数据。 我们遇到的问题是，RTP-MIDI 接收和处理消息的速度比我们在 iOS 上的简单 UDP 服务器快 20 毫秒左右。
我们编写了 3 个不同的代码库，以尝试消除代码中其他内容导致不可接受的延迟的可能性。 最后，我们得出结论，iPAD实际接收数据包的时间与该数据包实际呈现给我们的应用程序进行读取的时间之间存在滞后。
我们用示波器测量了这一点。每次发送设备发送Note-On命令时，我们都会对其中一个探测器进行脉冲。我们将另一个探头连接到iPad的音频输出上。 我们触发了脉冲并测量了听到音频所需的时间。 由此产生的时序是可靠的平均45毫秒，在极少数情况下最小为38毫秒，最大值约为53毫秒。
我们使用RTP-MIDI(一种更详细的协议(进行了完全相同的测试，它快了20毫秒。 我最好的预感是，作为CoreMIDI的一部分，RTPMIDI可能会比我们的应用程序获得更高的优先级，但简单地承认这一点对我们没有帮助。我们真的需要弄清楚如何解决这个问题。 我们希望我们的应用程序与RTPMIDI一样快，如果不是更快的话，我认为这在理论上应该是可能的，因为我们的协议不会那么混乱。 我们已经宣布RTPMIDI对于我们的应用程序来说是不可接受的，因为它的期刊系统设计不佳。
测试的 3 个代码库是：
-
Objective-C实现源自PGMidi示例，该示例将通过虚拟midi端口逐字转发UDP上接收的数据到GarageBand等。
-
Objective-C 源库由经验丰富的音频引擎开发人员编写，内置低延迟正弦波发生器用于输出。
-
具有基于单声道的UDP侦听器和内置声音字体合成器插件的Unity3D应用程序。
所有 3 种实现在示波器测试中都显示了相同的测量结果。
任何关于我们如何更快地获取消息的见解将不胜感激。
寻找答案的最新信息：
我四处寻找答案，我发现了这个问题，这似乎表明如果通信是TCP而不是UDP，iOS可能会更快地响应。 这需要我们付出一些努力来测试，因为我们的嵌入式系统缺乏TCP功能，只有UDP。 我很好奇我是否可以保持打开TCP连接的唯一目的是保持Wifi响应。 疯狂的想法？ 我不知道。 有人试过这个吗？ 我需要尽可能实时。
在这里回答我自己的问题：
事实证明，为了降低UDP延迟，我所要做的就是确保Wifi的静音时间不会超过150毫秒(左右(。 目前我还不知道确切的时间要求，但是我运行的初始测试是相隔 500 毫秒的数据包，而且太长了。 当我将数据包速率提高到每 150 毫秒 1 个时，UDP 延迟与 RTPMIDI 相当，使用我在原始问题中描述的相同技术，总延迟时间平均约为 18 毫秒(相对于 45 毫秒(。 这与我们的RTPMIDI测量值相当。