Error while debuging P3Speller: DataIOFilter::EvaluateTiming

[OKI]

Hello Guys,

i'm getting an error while i'm trying to debug the P3Speller.

BCI2000 V3 is running under MSVC++ 2008 on a Virtual Machine ( CUP 3* 1,6 GHz ~GB Ram) with Win7 x32 Bit.

I'm starting Operator, gUSBampSource and the P3SignalProcessing Module. And of course the P3Speller module compiled in MSVC++ 2008 in debug mode.

I'm preparing all settings and start the spelling session. After a few (10-20) flashes i get an error.
Here is the complete LOG paste:

2011-03-07T12:25:58 - BCI2000 Started
2011-03-07T12:25:59 - Waiting for configuration ...
2011-03-07T12:26:00 - Waiting for configuration ...
2011-03-07T12:26:18 - Waiting for configuration ...
2011-03-07T12:26:26 - Operator set configuration
2011-03-07T12:26:26 - Warning: gUSBampADC::Preflight: g.USBamp driver version = 3.2.
2011-03-07T12:26:27 - SignalProcessing confirmed new parameters ...
2011-03-07T12:26:27 - Application confirmed new parameters ...
2011-03-07T12:26:28 - SignalSource confirmed new parameters ...
2011-03-07T12:26:31 - Operator started operation
2011-03-07T12:26:45 - DataIOFilter::EvaluateTiming: Roundtrip time consistently exceeds block duration (currently 125.81%).

When i run the BCI2000 v3 P300Speller without debugging (install Version), there is no error during the session.

Greetings and thank you for answers,
Stefan

[gschalk]

Hi,

This simply means that BCI2000 cannot process the data as fast as they are coming in. In other words, don't use a virtual machine, use a faster computer, or compile in release mode.

Gerv

[gschalk]

Also, check this

http://www.bci2000.org/wiki/index.php/U ... nce:Timing

Gerv

[mellinger]

When compiled in debug mode, BCI2000 modules are running a lot slower than when compiled in release mode. This is because
1) the compiler does not perform any optimizations, and
2) a number of tests are performed that are not present in release mode, most prominently, in VS debug mode, array bounds are checked on every indexed access. This significantly slows down time-critical computations.

Rather than full debug mode, consider VisualStudio's "RelWithDebInfo" configuration, which builds in release mode but provides debugger symbols as well. This is perfectly suited in cases where you don't want assertions to be active, and don't need full variable information at all times. You will still be able to set breakpoints, step through code, and use a statistical profiler to profile the application.

Independently of that, you may disable the BCI2000 timing test for all source modules that don't connect to actual hardware, especially the SignalGenerator source module. Just specify
--EvaluateTiming=0
on the command line that starts up the source module in question.

Juergen