并行MIDI和BLE通信的WinRT / C ++问题

问题描述

在使用Windows的WinRT / C ++ API连接到MIDI端口并通过同一设备上的专有服务接收BLE通知时，我的团队一直在努力解决一个非常奇怪的问题。

WinRT / C ++库本身非常漂亮，并提供了简单而现代的C ++接口来访问托管Windows运行时类。

我已将sample repo推送到Github，在这里我们以一个最小的示例来复制该问题。

回购协议的自述文件详细解决了该问题，但是为了完整起见，我将在此处张贴相关内容。

该示例程序大致执行以下步骤：

• 使用DeviceWatcher检查可用的MIDI设备。

• 使用DeviceWatcher的另一个实例检查可用的Bluetooth LE设备。

• 在其ContainerId属性上匹配发现的MIDI和BluetoothLE设备（有关详细信息，请参见DeviceInfo）。这是JUCE在native WinRT code中为其库使用的方法，并且按预期工作。

• 打开MIDI端口，并将处理程序附加到MessageReceived事件（see the code）。

• 这将导致系统创建与Bluetooth LE设备的连接。程序检测到此状态更改，创建BluetoothLEDevice，执行GATT服务发现，并将处理程序附加到ValueChanged事件中，以处理我们感兴趣的来自（see the code）通知的特征。

然后，程序将计算每个端口上接收到多少MIDI消息以及从相应设备接收到多少BLE通知。

我们注意到的行为是来自最近连接的设备流的数据很好，而其他设备的吞吐量却受到严重限制。在这个问题上，我们处于停滞状态，并且不确定问题可能在何处。

我们在这里停滞不前。如果所有设备都表现出这种行为，我会更愿意接受，但事实并非如此。从同一外围设备创建MidiInPort和BluetoothLEDevice是否有任何原因会导致此问题？

解决方法

BLE无线电只能在任何给定时间接收或发送。因此，在任何给定时间只能与一台设备通信。当您有许多设备时，它使用调度程序为每个设备分配无线电时间。这样，第二个连接可以“中断”来自另一个设备的连接事件，从而降低了该设备的吞吐量。参见https://infocenter.nordicsemi.com/topic/sds_s132/SDS/s1xx/multilink_scheduling/central_connection_timing.html