I am observing inconsistent playback positions when using setPosition with FMOD_ACCURATETIME enabled. This is with FMOD_CREATECOMPRESSEDSAMPLE, loading mp3 files.
I am seeing this discrepancy with a waveform display that goes along with playback. The display of this waveform is updated 50 times per second and relies entirely on the PCM position returned by getPosition. If I let the sound play from start to finish, the waveform is completely in sync with the actual sound played.
But if I seek once or more times, then the actual sound played and the waveform does not match. The actual sound played comes later than what the waveform indicates. For a 5min length mp3 file of all kinds of bitrates I was able to observe delays up to 0.7s.
Could this be a FMOD bug?
- hyn asked 8 years ago
I’m still having this problem, but now I have some additional info.
What I did was compare the [b:36gjt0ws]sound being played[/b:36gjt0ws] in two test cases.
Case 1: Immediately after loading a song, setPosition to 5412864 in PCM samples. At this exact moment, getPosition in raw compressed bytes returns 3221214216. I capture the waveform display and record the sound that plays from here on out.
Case 2: Load the same song, this time play from start without setPosition. I have a breakpoint that triggers when getPosition PCM samples is exactly equal to 5412864. At this moment, getPosition raw compressed bytes returns 3221214216, the same as case 1. I capture the waveform display and record the sound that plays from here on out.
Then I compared the sound of 1 and 2, and noticed an obvious difference: case 1 misses the first beat that is present in case 2. The waveform display is exactly the same.
So, even though the returned PCM sample position and rawbytes position are the same between two cases, there is a difference in the played sound position.
I can’t think of any other way to debug this.
Using FMOD_TIMEUNIT_RAWBYTES with Channel::getPosition will return a format error. Are you sure the position you are getting is not simply a uninitialized variable? Logically if the compressed byte position was 3221214216 it would mean the file is around 3GB.
Sorry, you’re right. getPosition returns an error, so the rawbytes variable is garbage.
It doesn’t however affect my conclusion because the 2 sounds I hear are still markedly different. I tried the same experiment with another mp3 file, and came to the same result.
I tried FMOD_CREATESAMPLE instead of FMOD_CREATECOMPRESSEDSAMPLE and I am no longer experience this sync problem, so I think I can safely say this is an issue with the accuracy of FMOD’s seeking of compressed files.
I’m developing this for the iPad and unfortunately I don’t know how much memory is available (Apple has not given us any info) so FMOD_CREATESAMPLE may not be an option.
There are no issues with FMOD_CREATESTREAM, but I need seeking to be very responsive for my particular application, so for that FMOD_CREATECOMPRESSEDSAMPLE or FMOD_CREATESAMPLE is ideal. But as I said FMOD_CREATESAMPLE may not be an option (even though seeking is extremely responsive there).
So it’s an issue only with FMOD_CREATECOMPRESSEDSAMPLE.
The accuracy seems to be off by more than 1152 samples, at least judging from the sound I hear. I wouldn’t be able to recognize such a small difference (38ths of a second) just by hearing it. The delay I recognize is significant (~700ms). Also, accuracy seems to degrade as you seek further from the beginning.
Please login first to submit.