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