I am using a TrackIR4 camera with the OptiTrack SDK. When tracking information is read back at unhindered speed (can be tested by simply reading a frame and the first tracked object in it), the application eventually crashes inside an OptiTrack API call. This always happens for me, but the time it takes varies significantly - from almost immediately to after several hours. Most common is half a minute to perhaps five minutes.
Inserting an otherwise useless Sleep(10)-call in the loop removes the problem, but this should obviously not be needed.
(Shorter delays only make the crash take longer to appear, but I'd had no problems with the 10ms delay.)
[ August 16, 2006, 07:41 AM: Message edited by: wesslen ]
Crash when reading frame information too quic
Re: Crash when reading frame information too quic
quote:Originally posted by wesslen:
I am using a TrackIR4 camera with the OptiTrack SDK. When tracking information is read back at unhindered speed (can be tested by simply reading a frame and the first tracked object in it), the application eventually crashes inside an OptiTrack API call. This always happens for me, but the time it takes varies significantly - from almost immediately to after several hours. Most common is half a minute to perhaps five minutes.
Inserting an otherwise useless Sleep(10)-call in the loop removes the problem, but this should obviously not be needed.
(Shorter delays only make the crash take longer to appear, but I'd had no problems with the 10ms delay.)We will look into this. In the meantime, have you tried using the FrameAvailable notification? It will signal your application when new data is ready for processing.
I am using a TrackIR4 camera with the OptiTrack SDK. When tracking information is read back at unhindered speed (can be tested by simply reading a frame and the first tracked object in it), the application eventually crashes inside an OptiTrack API call. This always happens for me, but the time it takes varies significantly - from almost immediately to after several hours. Most common is half a minute to perhaps five minutes.
Inserting an otherwise useless Sleep(10)-call in the loop removes the problem, but this should obviously not be needed.
(Shorter delays only make the crash take longer to appear, but I'd had no problems with the 10ms delay.)We will look into this. In the meantime, have you tried using the FrameAvailable notification? It will signal your application when new data is ready for processing.
Re: Crash when reading frame information too quic
I had not. Thanks for the suggestion. I'll try that instead.