You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Clients should not be able to change the stream contents when it is known that Central's File.exe is recording.
IMO the NSP or hub should not know or care what another client is doing, so this feature should not be relied on and I think it should be impossible.
The better solution is for every application that is sensitive to changes in the contents of a datastream (e.g., visualization, processing with tight buffer sizes) to register a callback for config change packets, and to appropriately modify their operation (reset buffers or stop recording) when a config change is acknowledged.
However, even this isn't a perfect solution at the moment because it's currently possible in the Gemini system for packets to be out of order (config change acknowledged then old-config data packets come through for a few msec).
The text was updated successfully, but these errors were encountered:
Clients should not be able to change the stream contents when it is known that Central's File.exe is recording.
IMO the NSP or hub should not know or care what another client is doing, so this feature should not be relied on and I think it should be impossible.
The better solution is for every application that is sensitive to changes in the contents of a datastream (e.g., visualization, processing with tight buffer sizes) to register a callback for config change packets, and to appropriately modify their operation (reset buffers or stop recording) when a config change is acknowledged.
However, even this isn't a perfect solution at the moment because it's currently possible in the Gemini system for packets to be out of order (config change acknowledged then old-config data packets come through for a few msec).
The text was updated successfully, but these errors were encountered: