ios 消息服务器,iOS UDP服务器消息处理延迟太高〜35-40ms

我们正在实施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个代码库为：

从PGMidi例子这将转发逐字经由虚拟MIDI端口上UDP接收的GarageBand等

数据导出的目标C执行Objective-C源代码由有经验的音频引擎开发人员编写，内置低延迟正弦波发生器用于输出。

Unity3D应用程序，基于Mono的UDP监听器和内置的声音字体合成器插件。

所有3种实现方式在范围测试中显示了相同的测量结果。

任何有关如何更快地获得我们的消息的见解将不胜感激。在寻找答案

新的信息时：

我四处寻找答案，我发现this question这似乎表明，如果通信是TCP，而不是UDP的的iOS可能会更快速地响应。这需要一些努力来测试我们的部分，因为我们的嵌入式系统缺乏TCP功能，只有UDP。我很好奇我是否可以保持打开TCP连接的唯一目的是保持Wifi响应。疯狂的想法？我不知道。有没有人试过这个？我需要这样做尽可能实时。

+0

为什么你不想使用RTP-MIDI？ –

+0

我们不想使用RTP-MIDI，因为在MIDI流中发现损坏后，我们确定Apple的RTP-MIDI的实现存在缺陷，并且协议本身也存在相当的缺陷。例如，我使用App Store中流行的.MID文件播放器来播放16声道MIDI文件，并通过RTP-MIDI将它从最新的iPAD发送到Macbook Pro，并且经常损坏MIDI流。 –

+0

我比较了通过RTPMIDI与原始文件进行录制的同时还通过wireshark进行捕获。在很多情况下，Apple的日志恢复代码都会做出一些非常可怕和错误的事情，即使在原作中找不到原来无法找到的作品的笔记。我跑了很多测试。由于RTPMIDI中期刊设计的任意复杂性，我不应该责怪他们有错误的恢复。如果您想要更详细的评估，请查看[本博客](http://blog.digitaltundra.com/?p=24) –