Seek performance #156
Comments
|
Something like this: |
|
Working on this. |
|
I don't understand the importance of returning the samples in the scratch buffer - this poses a problem if the user expects to be able to seek backwards in a file efficiently. (Why should I seek to zero, then forward to the point I want to find?) I'm looking at solving this problem with a bit of a lack of breadth, so I'm probably an idiot and just haven't thought about the use cases enough... EDIT: yep. im an idiot; they're just discarded... |
|
Yeah, the scratch buffer is just for the "tape" seeking mechanism, so we don't need to allocate a buffer inside the function (or use humongous amount of stack). |
|
@Unit158 Are you still working on this? For me, seeking forward doesn't even seem to work at all, and seeking backwards sometimes does. It's quite unreliable. |


Right now, WaveStreamInstance::seek is implemented as succesive getAudio calls until the expected sample is hit, but that actually means that it decodes the audio data (an ogg for example) which is a big performance hit.
Couldn't we do this much more efficiently by calling stb_vorbis_seek and then just do a getAudio to get the correct sample position?
The text was updated successfully, but these errors were encountered: