Time synchronization & delays

Come here to discuss about OpenViBE in general!
Post Reply
Posts: 1
Joined: Wed Mar 18, 2020 8:49 am

Time synchronization & delays

Post by Arthur »

Hi everyone!

I'm trying to get a better understanding of how timing synchronization is handled in OpenViBE, with future real-time applications in mind.
Using some BCI protocols and experiments, some time desynchronization effects were observed by my colleagues.

The presence of a delay between the time of generation of a particular stimulation and the time of its processing by a box downstream (for instance, the stimulus being recorded by a CSV saver box) is not troublesome if this delay is short and has a small variance (enough to be considered constant, in order to be compensated).

Through a simple test protocol, I'm trying to evaluate how stimulation timestamps are propagated through a running scenario, to see if I can highlight time delays, and also evaluate the impact of processing box either along the way (e.g. acquisition server/client) or in parallel (with processing/visualization boxes running on the side).

So far, my test scenario is composed of :
  • a "Lua stimulator" box generating stimulations (LEFT & EOT) at regular intervals (250ms)
  • a "Display Cue Image" box displaying a simple white image upon reception of the LEFT stimulation, and a black one upon reception of the EOT stimulation, and which (if I understand correctly) transfers the stimulation to the Acquisition Server
  • The Acquistion Server generates a 16Hz Sawtooth signal, and sends it along with the received stimulations to the Acquisition Client
  • A few recording boxes save the stimulations (and signal when appliable) at different points in the chain : right after generating stimulations, and after the Acquisition Client (in order in that case to see the impact the Acquisition Server/Client mechanism has on the timestamps)
My observations and questions are the following :
  • Running OpenViBE on Linux (Ubuntu 16.04), the stimulation times recorded after the Acq Client are a few ms (15-20) after the ones recorded right at the generation of the stimulation.
  • However using Windows, the times recorded after the Acq Client are anterior to the ones at the generation (by ~30ms)... If I use a more complex scenario, keeping the core (LUA stimulator, ACQ Server/Client, CSV savers) but adding lots of signal processing boxes and visualizations, the recorded times
  • Do you have any idea of what would cause this seemingly incoherent effect on the timestamps? Maybe some modification or compensation that I did not take into account?
More broadly, those tests make me feel like maybe I'm misunderstanding the way timestamps and synchro are managed in OpenViBE. Do you have ressources linked to that topic, ideas on mechanisms to look into, or example real-time scenarios (or where time synchronization is a critical issue) I could have a look at?
(5.74 KiB) Downloaded 52 times

Posts: 230
Joined: Wed Oct 31, 2018 9:14 am

Re: Time synchronization & delays

Post by Thibaut »

Hello Arthur,
Great to have put so much information, plus an example scenario, it's perfect.

Firstly, an OpenViBE scenario runs "entirely" before trying again, so when all the boxes have performed their actions, it can start again. It cannot store pending streams. Therefore, each action can influence the fluidity of the program. This explains the slight desynchronization with the server acquisition which is a separate thread and does not suffer from the same lag at the same time. And therefore their timing is not comparable. The negative values ​​are probably due to the fact that there was a larger lag which caused the first element of your subtraction to have a lower timestamp (during a lag the timestamp is blocked).

If you look at the scenarios in BCI-examples (opened from no scenario or from an unregistered new scenario, it will place you directly in the folder with the example scenarios). You have the P300 Speller and there is precisely in this case a vital importance of the synchronization of the stimulations, they use TCP-Tagging to resynchronize the stimulations of openvibe with the acquisition but I admit that I have never looked into it concretely to see how it worked. there is a ticket on the site: http://openvibe.inria.fr/tcp-tagging/

Hope this can help you.


Post Reply