Seek performance

[jazzbre]

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?

[jazzbre]

Something like this:

void WavStreamInstance::seek(time aSeconds, float *mScratch, unsigned int mScratchSize) {

    if(mOgg)
    {
        double offset = aSeconds - mStreamTime;
        if (offset < 0)
        {
            if (rewind() != SO_NO_ERROR)
            {
                // can't do generic seek backwards unless we can rewind.
                return;
            }
            offset = aSeconds;
        }
        int samples_to_seek = (int)floor(mSamplerate * offset);
    
        stb_vorbis_seek_frame(mOgg, samples_to_seek);
        mOffset = stb_vorbis_get_sample_offset(mOgg);
        getAudio(mScratch, samples_to_seek - mOffset);
        mStreamTime = aSeconds;
    } else {
        AudioSourceInstance::seek(aSeconds, mScratch, mScratchSize);
    }
}

[Unit158]

Working on this.

[Unit158]

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...

[jarikomppa]

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).

[ghost]

@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.