WinRT/C++ 并发 MIDI 和 BLE 通信问题 [英] WinRT/C++ issue with concurrent MIDI and BLE communication
问题描述
在使用适用于 Windows 的 WinRT/C++ API 连接到 MIDI 端口并通过同一设备上的专有服务接收 BLE 通知时，我的团队一直在努力解决一个非常奇怪的问题.
My team has been struggling with a pretty strange issue while using the WinRT/C++ APIs for Windows to connect to both a MIDI port and receive BLE notifications through a proprietary service on the same device.
WinRT/C++ 库本身非常好，它提供了简单且现代的 C++ 接口来访问托管的 Windows 运行时类.
The WinRT/C++ library itself is really nice and provides easy and modern C++ interfaces to access the managed Windows runtime classes.
我已将 示例存储库 推送到 Github，我们在那里复制了一个最小例子的问题.
I've pushed a sample repo to Github where we've replicated the issue with a minimal example.
repo 的自述文件详细介绍了问题，但为了完整起见，我会在此处发布相关部分.
The repo's readme goes over the problem in detail, but I'll post the relevant bits here for completeness.
示例程序大致执行以下步骤:
The sample program is performing roughly these steps:
使用 DeviceWatcher.
使用 DeviceWatcher 的另一个实例检查可用的低功耗蓝牙设备.
Check for available Bluetooth LE devices using another instance of a DeviceWatcher.
匹配在其 ContainerId 属性上发现的 MIDI 和 BluetoothLE 设备(请参阅 DeviceInfo 了解详情).这是 JUCE 在 native WinRT 中采用的方法代码用于他们的库，并按预期工作.
Match discovered MIDI and BluetoothLE devices on their ContainerId property (see DeviceInfo for details). This is the method JUCE employs in the native WinRT code for their library, and works as expected.
打开 MIDI 端口并将处理程序附加到 MessageReceived 事件(见代码).
Open the MIDI port and attach a handler to the MessageReceived event (see the code).
这会导致系统创建与低功耗蓝牙设备的连接.程序检测到这种状态变化，创建一个 BluetoothLEDevice，我们执行 GATT 服务发现并将处理程序附加到 ValueChanged 事件，用于我们对来自 (查看代码).
This causes the system to create a connection to the Bluetooth LE device. The program detects this state change, creates a BluetoothLEDevice, we perform GATT service discovery and attach a handler to the ValueChanged event for the characteristic we're interested in notifications from (see the code).
然后程序会计算每个端口接收到多少 MIDI 消息以及从相应设备接收到多少 BLE 通知.
The program then counts how many MIDI messages are received on each port and how many BLE notifications are received from the corresponding device.
我们注意到的行为是来自最近连接的设备流的数据很好，而其他设备的吞吐量受到严重限制.我们在这个问题上处于停滞状态，不知道问题出在哪里.
The behaviour we notice is that data from the most recently connected device streams just fine, while the throughput for the others is severly limited. We are at quite a standstill regarding this issue, and are not sure where the problem may lie.
我们在这里处于停滞状态.如果所有设备都表现出这种行为，我会更愿意接受它，但事实并非如此.从同一个外设同时创建 MidiInPort 和 BluetoothLEDevice 是否会导致此问题?
We are at quite a standstill here. I'd be more willing to accept it if all the devices would exhibit this behaviour, but that's not the case. Is there any reason that creating both a MidiInPort and an BluetoothLEDevice from the same peripheral should cause this issue?
推荐答案
BLE 无线电只能在任何给定时间接收或发送.因此，在任何给定时间只能与一台设备通信.当您有许多设备时，它使用调度程序为每个设备分配无线电时间.这样，第二个连接可以中断"连接.来自另一台设备的连接事件，降低了该设备的吞吐量.请参阅 https://infocenter.nordicsemi.com/topic/sds_s132/SDS/s1xx/multilink_scheduling/central_connection_timing.html
A BLE radio can only receive or send at any given time. And therefore only communicate with one device at any given time. It uses a scheduler to allocate radio time for every device when you have many devices. That way a second connection can "interrupt" a connection event from another device, decreasing the throughput for that device. See https://infocenter.nordicsemi.com/topic/sds_s132/SDS/s1xx/multilink_scheduling/central_connection_timing.html
这篇关于WinRT/C++ 并发 MIDI 和 BLE 通信问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
