You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The latest version of the pupil labs LSL plugin forces Pupil capture service to use the LSL clock (great!). When frames are acquired from the video they get timestamped with an LSL timestamp. Sometimes frames get processed out of order and a recent sample can get pushed before an older sample. This is OK because they're timestamped with their LSL times from when they were acquired, and the stream is marked as irregular rate so there is no automatic dejittering.
Should streams with irregular rate be sorted by their timestamp on import? Is there a use case where this might be undesirable? e.g., "I want to know the order the samples were pushed; I don't care about their timestamps!" That seems pretty unlikely. I also think we don't have to worry about people using the timestamps for anything other than timestamps because they would have encountered problems from clock offset adjustment.
Are there technical reasons why we wouldn't want to support this in pyxdf? I'm guessing these streams would have to be eagerly loaded and couldn't be lazily loaded if lazy loading ever becomes a feature.
The text was updated successfully, but these errors were encountered:
The latest version of the pupil labs LSL plugin forces Pupil capture service to use the LSL clock (great!). When frames are acquired from the video they get timestamped with an LSL timestamp. Sometimes frames get processed out of order and a recent sample can get pushed before an older sample. This is OK because they're timestamped with their LSL times from when they were acquired, and the stream is marked as irregular rate so there is no automatic dejittering.
Should streams with irregular rate be sorted by their timestamp on import? Is there a use case where this might be undesirable? e.g., "I want to know the order the samples were pushed; I don't care about their timestamps!" That seems pretty unlikely. I also think we don't have to worry about people using the timestamps for anything other than timestamps because they would have encountered problems from clock offset adjustment.
Are there technical reasons why we wouldn't want to support this in pyxdf? I'm guessing these streams would have to be eagerly loaded and couldn't be lazily loaded if lazy loading ever becomes a feature.
The text was updated successfully, but these errors were encountered: