0
0

I am currently setting up a stream using the iOS low level API as such:

fmodSystem->createStream(path, FMOD_LOOP_NORMAL, 0, &bgm);

followed by playing the channel and attempting to seek to a specific time using

fmodSystem->playSound(bgm, 0, true, &channel);
channel->setPosition(position, FMOD_TIMEUNIT_MS);

However on iOS 10 this seems to cause a hang of around 4-6seconds depending on the file length.
The files I am using are 2-3min long .mp3 files all encoded with a constant bitrate so I’m not sure why this is happening. I’ve updated to version 10.8.15 and this still seems the case.
From my findings, the greater a position I set, the greater the freeze will be, as if the file is being read to seek.
This also does not occur on Android…

Does anyone have any insight into this? Is it a bug?
My current workaround is to specify FMOD_ACCURATETIME when creating the stream since creating the seek table causes no noticeable delay (despite it scanning the whole file!!) compared to seeking without one.

  • You must to post comments
0
0

If you don’t use FMOD_ACCURATETIME it has to read/decode and throw out frames until it hits the right byte offset as set by the sync header in the mp3 data. When it is VBR (as most mp3 data is) finding the right frame boundary is impossible.

The slowness must be something to do with the media , but the usual way to avoid the stream open blocking your app (and the setPosition) is to use FMOD_NONBLOCKING. It still takes the same amount of time but happens in the background.

  • You must to post comments
Showing 1 result
Your Answer

Please first to submit.