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