Closed opengenius closed 1 year ago
Thanks. I've pushed a fix to the dev branch.
I've also tried enabling unused onInitMemory path to go the pull exeucution path as more efficient one, seems to work fine).
static ma_result ma_decoder_init_from_vtable(... ... if (pDecoder->onRead == ma_decoderon_read_memory && pVTable->onInitMemory) { result = pVTable->onInitMemory(pVTableUserData, pDecoder->data.memory.pData, pDecoder->data.memory.dataSize, &backendConfig, &pDecoder->allocationCallbacks, &pBackend); } else { result = pVTable->onInit(pVTableUserData, ma_decoder_internal_on_readcustom, ma_decoder_internal_on_seekcustom, ma_decoder_internal_on_tellcustom, pDecoder, &backendConfig, &pDecoder->allocationCallbacks, &pBackend); }
I actually updated the dev branch yesterday so that ma_decoder_init_memory()
will use onInitMemory
if it's defined (will fall back to onInit
if not) so you shouldn't need to manually change the miniaudio code to use onInitMemory
anymore. Will be interested in your feedback on how that works if you were ever to try that.
Seeking to the loop start frame for vorbis in-memory file (pVorbis->usingPushMode) performs ma_stbvorbis_read_pcm_frames, which internally advances cursor, then cursor is beeing incremented again with framesRead (pVorbis->cursor += framesRead;), seems like this line is redundant.