Vorbis dev - Nov 2018 - Decode ogg file while downloading: what are the good practices?

OK, thanks for the information.
> Is the overhead of closing and re-opening the handle significant on
android?

Not that much: I can close, reopen and seek in a file right before
extracting samples to play a second audio file, while a first file is
already extracting and playing, without any glitch, even on low-end device.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/vorbis-dev/attachments/20181105/0896af60/attachment.html>

On 2018-11-05 12:55 AM, Matthieu Regnauld wrote:
>  > Is the overhead of closing and re-opening the handle significant on 
> android?
> 
> Not that much: I can close, reopen and seek in a file right before 
> extracting samples to play a second audio file, while a first file is 
> already extracting and playing, without any glitch, even on low-end device.
That's probably easiest, then. You can track when the download completes 
and skip the re-opening after that.

  -r

Hello,

After more tests, I discovered a new problem in my code (
https://gist.github.com/mregnauld/3f7cdc43b02ec3bbd91641b9333ba072) while
seeking in an audio file that is being downloaded.

When I seek in random positions (when I call OggPlayer::seek()), while I
extract audio samples (when I call OggPlayer::extract() every 5ms, in my
test - basically, I just play the audio file), sometimes, I get random
errors with ov_read():
- sometimes it returns 0 (end of file)
- sometimes it returns an error (like an OV_HOLE error)
- sometimes it just crashes

And that, even if I seek to a position which is at least 44100 frames (1
second) before the end of the file...

Has anyone had this problem? Is there maybe any buffer somewhere that I
forget to flush, or something?

Thanks for your help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/vorbis-dev/attachments/20181105/69e10898/attachment.html>