-
Notifications
You must be signed in to change notification settings - Fork 76
double-typed buff_len #146
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@tstenner had a good idea to make this typedef enum {
transp_default = 0, // keep legacy behavior
transp_buffsize_samples = 1, // the supplied int is in samples
transp_buffsize_thousandths = 2, // Indicates whether the supplied int should be (double)/1000
transp_synch = 4, // the outlet will use synchronous (blocking) zero-copy pushes
transp_disable_endianness = 8, // disable endianness conversions
} lsl_transport_options_t; |
This is such a trivial detail, but do we have any consistency as to whether the common short-form for 'buffer' should be |
…bandwidth streams where 1 sec is too long.
bad96d6
to
08024cc
Compare
Rebased on #155. Let's wait on that one to be merged so we can easily see the (comparatively very small) changes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Few minor things, but other than that an excellent addition
Rebased and merged in 0b35dba |
This adds new methods to the C API and an overloaded method to the C++ API to allow the user to set the buffer length with a double instead of an integer. This is necessary in very-high channel count and samplerate situations where even 1-second is too much. Obviously a sub-1-second buffer means that the system won't be able to recover from a disconnect without data loss but at these data rates that isn't really possible anyway (unless we want to start buffering to disk).