A possible time shift for the samples from g.Tec devices

[GoogleCodeExporter]

Hello,

Looking at the code for g.Tec devices in "mainwindow.cpp", it looks like there 
might be a shift in calculating the time stamps. Lines 288 - 292:

288: // reformat into send_buffer
289: for (int s=0;s<chunkSize;s++)
290:    for (int c=0;c<channelCount;c++)
291:        send_buffer[s][c] = src_buffer[c + s*(channelCount+1)];
292: double now = lsl::local_clock();

It seems that by moving line 292 to 288, the timestamp will be more accurate 
and the reformatting time will not be included in the timestamps.

Of course, this can be wrong if the "now" variable is not presenting the 
timestamp for the samples.

Thanks for the great software.

Original issue reported on code.google.com by hnezam...@gmail.com on 29 Jul 2014 at 11:15

[GoogleCodeExporter]

We'll address this -- but note that this is likely a very minor issue since 
that loop will typically finish in less than 100 microseconds, so the extra 
delay is less than a sample. 

Also note that if you really need to get the offset right to that precision you 
will have to measure the total system latency, including USB and driver 
latency, and account for it in your use of the data.

Original comment by christia...@gmail.com on 1 Aug 2014 at 10:06

• Changed state: Accepted