我正在使用MIDI-Over-Bluetooth，但是在iOS设备之间以及iOS和OSX Yosemite之间出现延迟问题。 Haven没有在桌面上进行任何广泛的测试，但是在设备之间有大约34ms的延迟，这对于MIDI来说太过分了。有没有人遇到类似的问题，有没有办法让一切变得更加活泼？
测试只是将时间戳发送到另一个设备，然后将其发送回原始设备。将当前时间戳和传输时间戳值之间的差异除以2，您就会得到非常粗略的延迟分数。
答案 0 :(得分：1)
正在寻找有关MD-BT01延迟的信息，没有找到任何信息，但之前的答案意味着至少20毫秒。
我发现有人已经计算出真正的鼓组（无软件）的延迟时间约为2毫秒。我对数学很可怕所以我无法确认。然而另一个来源（dawbench *）表明存在可以低至3毫秒的接口。另一个来源（androidaudiopathlatency）说，从Ipad测量的最低延迟是5毫秒。
我认为问题的一部分也是midi本身。当然，通过在线路的两端写入midi相关固件，您可能无法获得延迟，但是当有大量输入或输出时呢？它仍然是一个串行协议。当然，你可以通过说，暂时扭转节奏并将音符按时间调整到时钟等来解决这个问题 - 我想这是一对高声望的midi hw所做的事情（akai MPC就是这样做的，所以如果用户输入与运行循环相反，它将修复下一循环的时间。）
重点是，它仍然是一个黑客。如果你是专业级别的键盘手，并且不想听起来像鼓机凹槽但更像是爵士印象派，我就像...... 99.99％肯定你不能用midi做到这一点。这就是为什么Yamaha曾经有另一个端口绕过midi编码，即使在他们的入门级100美元midi键盘。但这当然只有DOS和Windows 98序列发生器支持。
点为＃2。要真正记录紧密的midi或任何东西，需要操作系统的驱动程序或mod来关闭各种现代操作系统功能，这样计算机基本上可以变成像模拟示波器那样精确的测量设备。或者......或许可以使用声卡作为“示波器”，制作一个硬件套件，将串行“midi”（yamaha）和常规midi转换为音频，然后同时使用第二个通道录制音频。然后你有一个midi信号和实际音频的音频表示（如果你演奏了一个产生midi +音频的合成器但是担心midi信号可能有你无法控制的延迟或抖动，因为它可能是由于您正在使用的来源） - 然后在录制后对齐计算机上的内容。
编辑： 引自“关于延迟的真相” “尽管许多音乐家都抱怨说MIDI本质上存在缺陷，因为8个音符会在八分钟内传播，因此现实情况是，在真实情况下听到它几乎是不可能的。”
一旦你知道0.5毫秒肯定是可察觉的，那么总结一下。我将此0.5毫秒的时间基于鼓槽软件，该软件可对凹槽进行微调。它可能是几乎紧密和紧密的鼓槽之间的区别。我刚刚才看到这句话。我希望在我尝试录制midi时我已经知道它并且非常沮丧为什么当我实时输入音符时感觉正确而在听到录制的midi（自由运行的音序器，没有量化）时感觉不舒服。
编辑2：
找到问题的插图！ http://www.spikenzielabs.com/SpikenzieLabs/Serial_MIDI.html 示波器镜头显示从微控制器发送到midi音符的延迟到计算机音频输出。 25毫秒！这应该是2毫秒，相当于模拟鼓。
答案 1 :(得分：1)
我认为一些答案令人困惑，因此我将尝试解释我对BLE延迟的了解。蓝牙设备无法持续通信。一旦连接了两个设备，它们将在每个“连接间隔”（这是连接开始时定义的参数之一）（从蓝牙规范开始，在7.5ms到4秒之间）中交换数据。
如果连接间隔为7.5ms，则并不意味着传输需要7.5ms。这意味着包每7.5ms发送一次。因此，7.5ms是数据在发送之前必须等待的最长时间（如果数据足够小，可以在一个包中发送）。 如果仅在蓝牙连接发生后准备好发送数据，则只有7.5毫秒的等待时间。在这种情况下，该数据将不得不等到下一个连接。
我们还需要增加驱动程序将要发送的数据转换为蓝牙数据包并通过无线电传输发送数据所需的时间。
结果如何：
无法确定连接间隔，这取决于中央设备。
答案 2 :(得分：0)
是否有人遇到类似问题
是的，我注意到了BLE MIDI的高延迟。
我的设置是雅马哈无声钢琴，它有一个MIDI端口。我使用MD-BT01加密狗，通过BLE将MIDI信号传送到iPad。
播放音符和听到声音之间的总时间（直接来自iPad，而不是BT音频，这将导致更多的延迟）是显而易见的，并且会分散注意力。
有没有办法让一切变得更加活泼？
我不相信你可以做很多事情，因为某些时间限制被写入BLE MIDI规范。我的研究产生了一些值得阅读的链接：
我的结论：
答案 3 :(得分：0)
我知道这已经讨论了一段时间了，但是我认为对于实际的蓝牙LE（低功耗）时序仍然存在很多困惑，所以我希望以下内容可以对此有所澄清。
蓝牙LE以特定的连接间隔发送数据包。最小的时间间隔是7.5ms。另外，根据您的硬件使用的Bluetooth LE版本，每次传输期间可以发送的数据包（有效负载）的最大长度也将有所不同。对于Bluetooth LE V4.0，最大有效负载长度为20个字节。对于较新的版本（4.2、5.0），增加了数据包长度扩展，因此现在可以每7.5ms发送最多250个字节。因此，对于使用V4.0 BLE（蓝牙LE）的硬件，如果您一次需要发送20个以上的字节，则将需要多个连接间隔。假设您需要发送30个字节（例如，如果您在键盘上同时演奏10个音符，则很容易发生这种情况），则至少需要13毫秒（2 x 7.5毫秒）来传输30个字节。 / p>
这里还有另外一个因素。大多数智能设备不允许最快的7.5ms连接间隔，因为它们的软件还必须处理系统硬件的其他部分。因此，它们允许的最低连接间隔通常为30ms，这在延迟方面非常明显。这通常是用户无法控制的，因为连接间隔是在链路层级别上协商低功耗蓝牙设备之间的连接间隔（在硬件中深入了解，由蓝牙协议决定）。因此，我对许多用户（例如上面的Dennis George）报告的延迟大约为30毫不感到惊讶。
我现在在2019年底写这篇文章，但是基本上问题还是一样。低功耗蓝牙从未真正设计用于流式传输大量数据。最近的数据包长度扩展确实有帮助，但是延迟始终是一个问题。
答案 4 :(得分：-1)
根据the PR of some Bluetooth latency-optimized product，
[我们的酷炫产品]提供的总端到端延迟仅为32毫秒（ms） - 远远低于超过150毫秒（+/- 50毫秒）的标准蓝牙延迟。
因此，如果您使用自己的代码大约需要34毫秒，那就更好了。
蓝牙不适合实时MIDI。