createSound takes more time in new fmod stduio

FMOD Studio
1

recently i was doing the integration of fmod studio in Vision Engine, i found that the new createSound api in fmod studio takes longer than the old version in fmod ex when load the sound the first time, and further i found it’s mostly likely the decompress-processing that takes longer…
i tried the sample from the sdk of the fmod studio and it’s the same.

here is the code fragment:

Initialization:

	FMOD::Studio::System::create(&m_kStudioSystem);
	m_kStudioSystem.getLowLevelSystem(&m_pFmodSystem);

	if(!m_pFmodSystem)
		return;

	m_pFmodSystem->setFileSystem(VisionFM_Open, VisionFM_Close, VisionFM_Read, VisionFM_Seek, NULL, NULL, 4096);
	m_pFmodSystem->setSoftwareFormat(48000, FMOD_SPEAKERMODE_DEFAULT, 2);

	FMOD::Memory_Initialize(0, 0, VisionFM_Alloc, VisionFM_Realloc, VisionFM_Free, 0);

	m_kStudioSystem.initialize(128, FMOD_STUDIO_INIT_NORMAL, FMOD_INIT_NORMAL, 0);

	//TODO: some advance settings here
	m_pFmodSystem->set3DSettings(1.0f, 1.0f, 1.0f);
	m_pFmodSystem->getMasterChannelGroup(&m_pMasterChannelGroup);

Create Sound Resource:

	if(!FmodStudioManager::GlobalManager().IsInitialized())
		return FALSE;

	FMOD_MODE eOpenMode = FMOD_SOFTWARE | FMOD_3D_LINEARSQUAREROLLOFF | FMOD_IGNORETAGS | FMOD_LOWMEM;
	eOpenMode |= FmodStudioManager::HasFlag(m_iResourceOpenFlag, V_FMOD_CREATE_STREAM) ? FMOD_CREATESTREAM : FMOD_CREATESAMPLE;
	eOpenMode |= FmodStudioManager::HasFlag(m_iResourceOpenFlag, V_FMOD_CREATE_3D) ? FMOD_3D : FMOD_2D;
	eOpenMode |= FmodStudioManager::HasFlag(m_iResourceOpenFlag, V_FMOD_CREATE_ASYNCRONOUS) ? FMOD_NONBLOCKING : 0;
	
	FMOD::System* pLowSystem = FmodStudioManager::GlobalManager().GetFmodSystem();
	FMOD_CREATESOUNDEXINFO extrainfo;
	memset(&extrainfo, 0, sizeof(FMOD_CREATESOUNDEXINFO));
	extrainfo.cbsize = sizeof(FMOD_CREATESOUNDEXINFO);
	extrainfo.initialsubsound = 1;
	pLowSystem->createSound(GetFilename(), eOpenMode, &extrainfo, &m_pSound);

	if(!m_pSound)
		return FALSE;

	return TRUE;

plz help me…

2

Why not choose the first codec to try based on the filename extension?
Seems odd to try the mp3 codec last if the filename ends with “.mp3”

3

If you mean in the fmod code, that’s probably not a bad idea. The reason mp3 is last is that it can easily find a byte pattern in any other type of file that matches mp3, and then decide to go ahead as mp3, when it is in fact a wav file for example. We have files that dont use the correct extension (ie a .wav that is actually an mp3) but they are a rarer case and it wouldn’t be a big issue if these took longer.

4

Yes I meant the fmod code. Currently I have to manually myself look at the extension and suggest a codec type to speed up codec detection.
This should be done inside fmod imo.

5

right - yes it could be to do with more logging.

6

Hi humphrey,
Is this for mp3 data? The mp3 codec is the same as FMOD Ex , so the decompress shouldnt take longer - maybe there are more codecs to scan.
If you let me know the format you’re using and the size of it, i can do a comparison test here.

I would probably recommend not decompressing your sounds on load - but that depends on how many sounds you have and your use case. FMOD_CREATECOMPRESSEDSAMPLE is a better option these days.
Also if you know the format, use FMOD_CREATESOUNDEXINFO::suggestedsoundtype to skip any codec scanning - there are 30 or so codecs supported now (though it checks the common ones first like WAV and FSB). Because mp3 is byte scanning (it has no header) it is actually checked last.

7

hi， thanks for replying… the sound file type is ogg and i used a debug version of the fmod last time and actually i didn’t do a precise performance test for the release version.
now i use the release version and can’t tell the difference between the fmod ex and the fmod studio.
so if there are more debug information in new fmod that makes the debug version takes more time to create a new sound.
also thanks for the advice that set the suggestedsoundtype.