0
0

Hi,

I’m currently evaluating fmod. As a new user to FMod Ex, it’s likely I’m doing something stupid or wrong.

I’m creating an sound with the following ‘mode’ flags:

FMOD_OPENMEMORY | FMOD_CREATESTREAM | FMOD_OPENRAW

The sound is approximately 64kb. My streaming buffers are set to 16kb.

The call to FMOD_System_CreateSound is regularly taking 20ms. Can anyone explain why this is so slow? If I remove the ‘FMOD_CREATESTREAM’ flag, then the call regularly takes about 0.4ms. Can anyone explain this discrepancy?

Also, is anyone using fmod in a case where they have thousands of sounds, which would be impracticle to load all at once? It seems like a long time to create a new sound.. Even the 0.4ms case is taking a long time if you are shooting for 16-ms per update in your application. How are other users who stream all of their content from disk creating new sounds on the fly?

thanks,
sam

  • You must to post comments
0
0

If you want to improve createSound time do these 3 things.

  1. Use FMOD_CREATESOUNDEXINFO and suggestedsoundtype entry.
  2. Use FMOD_LOWMEM flag to avoid some allocs.
  3. Use FMOD_IGNORETAGS flag to avoid tag scanning.
    and maybe
    (4. Don’t use FMOD_ACCURATETIME flag.)
  • You must to post comments
0
0

[quote="brett":gjh7dri6]If you want to improve createSound time do these 3 things.

  1. Use FMOD_CREATESOUNDEXINFO and suggestedsoundtype entry.
  2. Use FMOD_LOWMEM flag to avoid some allocs.
  3. Use FMOD_IGNORETAGS flag to avoid tag scanning.
    and maybe
    (4. Don’t use FMOD_ACCURATETIME flag.)[/quote:gjh7dri6]

Hi Brett,

I implemented your suggestions into the example, and the create time is still around 6ms.

In the context of a 16ms update, that’s a big chunk of time for us.

Maybe my expectations are unrealistic, but we’re hoping to devote <=1ms to sound each update.

Do you have any other suggestions or ideas to help reduce the time further?

thanks,
sam

  • You must to post comments
0
0

Hello,

Maybe you can try setting the loading of sounds to non-blocking (does not stop the app main thread).
About streaming from file, in every case it’s an expensive operation (it can easily be 1000x slower than streaming from memory)

If you want to stream many sounds (maybe hundreds), you may want to have samples compressed in memory. If you have, say, 200 sounds 5 seconds long each, you may need about 10Mb in memory, if I’m right. And 10mb is not that much.

If you look closer at the documentation you’ll see that not using the createstream flag implies loading the sound once from the disk.
With this flag on, you ask FMOD to output sound from disk. Cannot be acceptable for multiple sounds at once.

Then if you want to load more sounds faster than one by one, you can try using sound font formats : as you may know, they consist in a file containing several sounds. They are faster to load because you don’t suffer the overhead of opening and closing files.

Hope I’ve been of any help.

  • You must to post comments
0
0

Its possible its the first stream you create, that it creates some threads and sets up other singleton type stuff.

Do you get the same hit on the 2nd stream? There are criticalsections involved in creating streams if i remember correctly too.

  • You must to post comments
0
0

It seems to be constant.. It really depends. Sometimes, it takes < 1ms to create a stream; other times it takes 10ms or 20ms. It doesn’t seem to vary based on it being the 1st, 2nd, etc. that I create.

-sam

  • You must to post comments
0
0

I modified the "realtimestitching" sample, adding a high resolution timer around the place in the code where it calls FMOD_System_CreateStream:

[code:210l1wkr]
/*
Replace it with a new sound in our list.
*/
result = FMOD_System_CreateStream(system, soundname[sentenceid], FMOD_DEFAULT, 0, &subsound[subsoundid]);
ERRCHECK(result);
[/code:210l1wkr]

This call is consistently taking between 6 and 8 milliseconds. Does this help at all?

thanks,
sam

  • You must to post comments
0
0

I did the same thing and see between 2-3ms. Do you get spikes of "10ms or 20ms" in your modified realtimestitching test? If not can you think of a way to reproduce these spikes?

  • You must to post comments
0
0

Hi Andrew,

I didn’t see spikes up to 10 or 20ms when i modified the example, but I will try to figure out a way to reproduce that. It probably has something to do with the data, I’m guessing. Anyways, I’ll work on it.

I’m not sure why my fmod is 3x slower than yours.. I know my sound card sucks.. could that be a factor? Also, I’m running fmod version 4.04.30. Are there any enhancements that you know of that would explain the differences we’re seeing? I’m running the "Release C" version. hmm.

thanks,
sam

  • You must to post comments
0
0

Yes, there have been speed improvements since .30 and many other fixes/improvements as well. Please get the latest version so we can compare like to like.

  • You must to post comments
0
0

Ok, I’ve grabbed version 4.04.51 and rebuilt the sample.

Using my test wav file, it doesn’t look like much has changed:

[code:1bs0m5g6]

PlayStream Example. Copyright (c) Firelight Technologies 2004-2005.

Press space to pause, Esc to quit

FMOD_System_PlaySound took 23.41 ms
FMOD_System_PlaySound took 23.38 ms
FMOD_System_PlaySound took 23.66 ms
FMOD_System_PlaySound took 23.31 ms
FMOD_System_PlaySound took 23.41 ms
FMOD_System_PlaySound took 23.42 ms
FMOD_System_PlaySound took 23.68 ms
FMOD_System_PlaySound took 23.42 ms
FMOD_System_PlaySound took 23.39 ms
FMOD_System_PlaySound took 23.26 ms
FMOD_System_PlaySound took 23.41 ms
FMOD_System_PlaySound took 23.37 ms
FMOD_System_PlaySound took 23.40 ms
FMOD_System_PlaySound took 23.48 ms
FMOD_System_PlaySound took 23.39 ms
FMOD_System_PlaySound took 11.67 ms
FMOD_System_PlaySound took 11.65 ms
FMOD_System_PlaySound took 11.66 ms
FMOD_System_PlaySound took 11.68 ms
FMOD_System_PlaySound took 11.67 ms
FMOD_System_PlaySound took 11.68 ms
Time 00:04:11/01:31:39 : Playing
[/code:1bs0m5g6]

I’ll keep playing around with the new version and see if I notice any differences.

thanks,
sam

  • You must to post comments
0
0

Ugh, sorry, getting my threads on this message board mixed up.

I reran the stitching example with 4.04.51, and it’s still taking me between 6-8ms to create the streams.

I’ll still working on a reproduceable case with spikes up to 10ms/20ms.

-sam

  • You must to post comments
Showing 11 results
Your Answer

Please first to submit.