0
0

[code:3g94d4mw]FMOD_RESULT result = m_pChannel->getPosition(&pos, FMOD_TIMEUNIT_PCMBYTES);
m_pChannel->getPosition(&pos2, FMOD_TIMEUNIT_MS);

FMOD::Sound* sound;
m_pChannel->getCurrentSound(&sound);

unsigned int length = 0;
sound->getLength(&length, FMOD_TIMEUNIT_PCMBYTES);

unsigned int length2 = 0;
sound->getLength(&length2, FMOD_TIMEUNIT_MS);

dbAssert(pos2 <= length2);
dbAssert(pos <= length);[/code:3g94d4mw]

I’m using the above to test things out as my dbasserts are getting triggered, it seems like the MS assert isn’t triggered which is good, however I’m encountering cases where the current channel position in pcmbytes is more than the actual sound length in pcmbytes. I’m confused as to why this would be the case. The sounds in question are ADPCM and opened as compressed samples but I don’t think that should make any difference? Or does the fact that the sound is looping causes something like this?

Unless… the source is mono and the channel is playing back in stereo?! But if that’s the case how can I properly reconcile the difference in all speaker setups?

  • You must to post comments
0
0

mb
my guess….
aChannel->getPosition is not byte accurate but channel buffer size accurate in bytes. it would be very difficult to get such accurate positioning and would require you to write your own stream reading. as part of this, looping a stream (channel), i have found, can give you the result you are getting. as for why you get more bytes than length, my guess is that the channel buffer is not completely full at the end of your looped sound and so the rest of the buffer is filled with the start of the looped sound data. so, at the end of that buffer fill cycle, the channel has passed the end of the sound but has continued to fill the buffer increasing the bytes-read position.

  • You must to post comments
0
0

What format is the sound?

  • You must to post comments
Showing 2 results
Your Answer

Please first to submit.