LSL stream data delay

[retiutut]

Problem

Multiple users report a delay in stream data over LSL.

https://openbci.com/forum/index.php?p=/discussion/2225/delay-in-stream-data-from-openbci-gui-to-matlab-2019#latest

Expected

For LSL streaming to work smoothly for all users

Operating System and Version

Usually Windows or Linux

GUI Version

4.1.x

Running standalone app

Usually standalone. LSL has been fixed in standalone since 2019.

Type of OpenBCI Board

All board types

Are you using a WiFi Shield?

No

Console Log

No errors are showing in the GUI, though it is worth mentioning this issue that was resolved recently: #530 . So, now all LSL data streams should have a timestamp.

[retiutut]

Seems to be working with 4.1.6!

Tested with Matlab R2019b and Windows 10 and GUI 4.1.6.

[retiutut]

All of my tests on this issue have been using 64bit applications.

[retiutut]

Proof of no lag between GUI/Matlab:

• I press the stop button in GUI and the stream stops immediately
• exact same Accelerometer values in both apps
• I press start button in GUI and the stream starts immediately

[retiutut]

Python Tests:
https://github.com/OpenBCI/OpenBCI_GUI/tree/master/Networking-Test-Kit/LSL

[retiutut]

Ganglion+WiFi @ 1600Hz Streamed to OpenVibe via LSL with no lag:
https://www.youtube.com/watch?v=97rNewfbTKA

Device drift in the OpenVibe Acquisition server seems to account for when there are too few or too many samples received based on the sample rate (ex. 1600Hz). There's a section of the video where I intentionally make the GUI framerate drop by viewing 20 seconds of TimeSeries data. This is a known issue that plans to be resolved by downsampling what is actually drawn in the GUI. Still, I wanted to see how this would affect the LSL stream, and it causes "drifting"!

Towards the end of the recording the device was tapped a few times, and this shows up at the same time in the GUI and Openvibe even though drift is ~-82,000ms.