0
0

Hey guys,

I’m seeing a bit of an issues. The version of FMOD I’m using is 4.26.06. I took a look at the release notes, but didn’t see anything that looked like it solved this issue in particular.

I’m creating a streaming sound with the following flags: FMOD_OPENMEMORY | FMOD_CREATESTREAM | FMOD_NONBLOCKING | FMOD_SOFTWARE | FMOD_3D_CUSTOMROLLOFF | FMOD_3D

I’m passing in a memory buffer with mp3 data. The file plays fine, but the channel->isPlaying() function always reports CHANNEL_STATUS_PLAYING, even after it is clearly finished.

Is this a known issue that’s fixed in the current library, or can you guys reproduce this?

  • You must to post comments
0
0

I have more info to report:

I upgraded our libraries to the latest stable release, and the error still occurs.

I did notice, however, that I was incorrect in stating it never reported the channel as stopped. When I played a piece of music, the channel reported the play state between two to three times the actual length of the piece of music. It definitely was related to the original length of the piece, as when I played shorter or longer pieces, the delay at the end changed respectively.

Our engine supports both mp3 and Ogg Vorbis audio data. This does not occur with Vorbis data.

The inaccurate play status reporting does not happen if you use the FMOD_ACCURATETIME flag.

Edit: another point I should clarify… this only happens with streaming sounds, not with static samples.

  • You must to post comments
0
0

I would recommend sending the mp3 file to us so we can try it here. I assume you’re setting the memory length value correctly and FMOD_ACCURATETIME isnt trying to scan past the end of your memory buffer? This is what it sounds like to me.

  • You must to post comments
0
0

Short version: not a bug in fmod. I’m an idiot, and was using LAME wrong.

Long version: I think I got it figured out. I had a funky setting in LAME that was likely causing some odd output in the final mp3 files. Specifically, I was using the -t flag AND the -V n flag, which seemed to cause issues. I think I misread what the -t flag was for, thinking it stripped out some extraneous data when encoding, when in fact, it’s a decoding flag.

The -V n flag is a variable bitrate quality setting. I guess the two flags don’t play together.

If you want to reproduce this yourself, you can just type:
lame -t -V 5 somefile.wav somefile.mp3

I modified the playstream sample to load from memory (using code swiped from loadfrommemory sample), and I was able to reproduce the issue. However, this is certainly a bug in LAME (although with a high degree of user error), not fmod. I opened the file in WinAmp, and it reported the same extended time I saw in fmod.

  • You must to post comments
0
0

Cool thanks for the information about lame, glad to see you sorted it out.

  • You must to post comments
Showing 4 results
Your Answer

Please first to submit.