0
0

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?

  • You must to post comments
0
0

Hi, I just sent an email to support with the title "Compressed sound seeking problem ".

  • You must to post comments
0
0

Hi,

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.

  • You must to post comments
0
0

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.

  • You must to post comments
0
0

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.

  • You must to post comments
0
0

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.

  • You must to post comments
0
0

Have you tried FMOD_CREATESTREAM? do you have issues here? You will probably want to stream audio that is 5 minutes long anyway. Create compressed sample will still take up a lot of memory for large compressed files.

  • You must to post comments
0
0

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.

  • You must to post comments
0
0

Due to the way compressed sample works with MP3 you can only seek accurately to MP3 frame boundaries which is 1152 samples.

  • You must to post comments
0
0

Hi,

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.

  • You must to post comments
0
0

Could you send us an example that reproduces this problem to support@fmod.org, possibly a modified version of one of the FMOD examples along with the media you are using?

  • You must to post comments
Showing 10 results
Your Answer

Please first to submit.