FMOD_ASYNCREADINFO offset is not in order

FMOD Engine
1

Hi,

If you read this archived topic, it will be easy to understand my situation.
Asynchronous I/O Problems

Like above topic says, using FMOD_IGNORETAGS prevents the first non-ordered offset request. But after first few requests, FMOD still request non-ordered offset. ( the offset positions are mostly end of file).

My sound buffer is filled in another thread, so I can’t let FMOD seek not in order. I must find the way to be requested in order.

Anyone has a good idea?

  • You can reproduce this on FMOD Studio API 1.10.10’s lowlevel example ‘asyncio’. I’m using Microsft Visual Studio Professional 2015 Update 3 to build this example.
  • My goal is playing ogg vorbis files on Android.

Thanks.

2

So far I am unable to reproduce the issue here.
Are you able to send us any files and modifications you have made to the asyncio.cpp?

3

Hi Cameron,

I didn’t make any modification on asyncio.cpp but createStream().

result = system->createStream( Common_MediaPath( “singing.wav” ), FMOD_LOOP_NORMAL | FMOD_2D | FMOD_IGNORETAGS, NULL, &sound );
result = system->createStream( Common_MediaPath( “singing.ogg” ), FMOD_LOOP_NORMAL | FMOD_2D | FMOD_IGNORETAGS, NULL, &sound );

I can reproduce this using ‘singing.wav’ which is included in the example, and the ogg file encoded from the wav file( I used oggenc.exe v2.87 and Audacity v2.3.0 for ogg encoding )

When I play ‘singing.wav’ 467,866 bytes file,
#1 FMOD_ASYNCREADINFO: offset 0, sizebytes 2048
#2 FMOD_ASYNCREADINFO: offset 466944, sizebytes 2048
#3 FMOD_ASYNCREADINFO: offset 0, sizebytes 2048
#4 FMOD_ASYNCREADINFO: offset 2048, sizebytes 34816
#5 FMOD_ASYNCREADINFO: offset 18432, sizebytes 18432
#6 FMOD_ASYNCREADINFO: offset 34816, sizebytes 2048
#7 FMOD_ASYNCREADINFO: offset 18432, sizebytes 18432
…

When I play ‘singing.ogg’ 52,808 bytes file,
#1 FMOD_ASYNCREADINFO: offset 0, sizebytes 2048
#2 FMOD_ASYNCREADINFO: offset 0, sizebytes 8192
#3 FMOD_ASYNCREADINFO: offset 8192, sizebytes 2048
#4 FMOD_ASYNCREADINFO: offset 43008, sizebytes 2048
#5 FMOD_ASYNCREADINFO: offset 45056, sizebytes 6144
#6 FMOD_ASYNCREADINFO: offset 51200, sizebytes 2048
#7 FMOD_ASYNCREADINFO: offset 2048, sizebytes 2048
#8 FMOD_ASYNCREADINFO: offset 4096, sizebytes 8192
#9 FMOD_ASYNCREADINFO: offset 12288, sizebytes 2048
…

I noticed the offsets poped to the last part of file.

4

What version of FMOD are you using?

5

#define FMOD_VERSION 0x00011010

I downloaded it on 2018.12.10.

6

I am still unable to get the same results as you, it looks like the IgnoreTags isn’t being used for some reason.
My results:

REQUEST 16384 bytes, offset 16384 PRIORITY = 0.
FED 16384 bytes, offset 16384
REQUEST 32768 bytes, offset 32768 PRIORITY = 50.
FED 16384 bytes, offset 32768
REQUEST 16384 bytes, offset 49152 PRIORITY = 50.
FED 3561 bytes, offset 49152 (* EOF)

7

the .wav format will scan the whole file because .wav is a riff chunk based format. It does scan to the end.
This is not related to tags, it is just checking all chunks.
We could put in an optimization not to scan to the next chunk if the offset + chunksize >= filelength, but it is not a good idea to assume any file wont have weird seeking habits. Some file formats just store data at the end that needs to be retrieved.

This is why .FSB was created, it is seekless, and low read. An FSB can read twice (1. header, 2. sample header block), and seek never, then it is done.

8

I might look into this a bit further, because unless there is more data after the data chunk, it should not issue a read callback. I’ll let you know what I find

9

Thank you guys.

Firstly I implemented random access function to allow scanning, and now my project with fmod works fine.
But I’ll try to encode my sound files to .fsb and see if it doesn’t seek.