search for: op_seek_func

...c, Clearly I haven't thought these changes through properly and was only really considering common desktop systems. I was originally fixing an issue when compiling my code as 64bit where my use of int64_t (defined as long on my platform) was conflicting with the opusfile stream callbacks (e.g. op_seek_func) which were using the opus_int64 type which was defined as long long. When I looked at the header I thought it could do with some work, so instead of putting casts in my code, I modified the header and sent a patch. I didn't even consider building for architectures which could have a 40bit long...

...the opus > audio in chunks. So I am not sure if the Opusfile seek API will work in > this case. Please correct me if I am wrong. If you don't want to use opusfile's http client implementation (libopusurl) you can still use its seeking implementation. Just provide the `op_read_func`, `op_seek_func`, and `op_tell_func` callbacks on top of your current fetch framework. The library will call your seek implementation with the necessary byte offsets to find and resume decoding at the requested position when you call op_pcm_seek(). > Is there anyway to get or calculate the byte offset correspo...

On 2016-11-08 1:59 AM, Philipp Schafft wrote: > Some notes: > * libvorbisfile has a nice implementation of that, it also takes > care of matching the signal at the very point of the jump. I would recommend the opusfile library, which implements seeking specifically for Opus streams. https://archive.mozilla.org/pub/opus/opusfile-0.8.zip

- Replaced blanket #define of 8 & 64 bit types with typedefs for each platform to match 16 & 32 bit types. - Updated existing typedefs for each platform to fix odd values and improve consistency. --- include/opus_types.h | 125 ++++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 100 insertions(+), 25 deletions(-) diff --git a/include/opus_types.h