Needs investigation. Reported by Thomas on Discord
When creating a loopback endpoint with MidiLoopbackManager:CreateTransientLoopback and then calling MidiBasicLoopbackManager:RemoveTransientLoopback (yes, the basic version!) with same the GUID used for creating the loopback endpoint leads to some error in MidiSrv:
The running device watchers (standard and legacy) suddenly send Removed events for each endpoint, but no Stopped event. Newly created watchers also refuse to provide any endpoints at all until MidiSrv gets restarted!
The same happens when doing this vice versa: MidiBasicLoopbackManager:CreateTransientLoopback -> MidiLoopbackManager:RemoveTransientLoopback
My response:
Stopped is only raised when you stop the watcher.
These watchers are backed by an underlying Windows.Devices.Enumeration.DeviceWatcher and so obey the same rules and flow. You can see the states and information here:
https://learn.microsoft.com/en-us/uwp/api/windows.devices.enumeration.devicewatcher?view=winrt-28000
I'll double-check the service code to ensure that it's validating the association id is one it owns in that transport, and isn't from a different transport. Thanks.
Not sure on the newly created watchers problem though. That's not something that has appeared in any of my tests. My guess is the bad association id has cause an error in the service that it isn't recovering from, and so no new endpoints are being created (and therefore not enumerated by pnp)
Looking in the service, the basic loopback plugin guards against invalid association ids, so you shouldn't see this behavior.
I'll need to write some tests to repro it. Thanks.
Needs investigation. Reported by Thomas on Discord
When creating a loopback endpoint with MidiLoopbackManager:CreateTransientLoopback and then calling
MidiBasicLoopbackManager:RemoveTransientLoopback(yes, the basic version!) with same the GUID used for creating the loopback endpoint leads to some error in MidiSrv:The running device watchers (standard and legacy) suddenly send
Removedevents for each endpoint, but noStoppedevent. Newly created watchers also refuse to provide any endpoints at all until MidiSrv gets restarted!The same happens when doing this vice versa:
MidiBasicLoopbackManager:CreateTransientLoopback -> MidiLoopbackManager:RemoveTransientLoopbackMy response:
Stopped is only raised when you stop the watcher.
These watchers are backed by an underlying
Windows.Devices.Enumeration.DeviceWatcherand so obey the same rules and flow. You can see the states and information here:https://learn.microsoft.com/en-us/uwp/api/windows.devices.enumeration.devicewatcher?view=winrt-28000
I'll double-check the service code to ensure that it's validating the association id is one it owns in that transport, and isn't from a different transport. Thanks.
Not sure on the newly created watchers problem though. That's not something that has appeared in any of my tests. My guess is the bad association id has cause an error in the service that it isn't recovering from, and so no new endpoints are being created (and therefore not enumerated by pnp)
Looking in the service, the basic loopback plugin guards against invalid association ids, so you shouldn't see this behavior.
I'll need to write some tests to repro it. Thanks.