when I play music with FMOD Ex I get a huge performance hit, CPU average load is ~20%.
In comparison, when using iPhone AudioToolbox the CPU average load is only 4% or less.
Am I doing something wrong here?
The MP3 is a 128kbps stereo file, and was tested on iPhone 3G, iPhone OS 3.1, FMOD version 42606.
[code:32c7bzsx]// Simple Mp3 music test
SAFE_FMOD( FMOD::EventSystem_Create( &m_pEventSystem ) );
SAFE_FMOD( m_pEventSystem->init( 32, FMOD_INIT_NORMAL, NULL, FMOD_EVENT_INIT_NORMAL) );
SAFE_FMOD( m_pEventSystem->getSystemObject( &m_pSystem ) );
SAFE_FMOD( m_pSystem->createStream( (m_strResourcePath+"menu.mp3").c_str(), FMOD_HARDWARE | FMOD_LOOP_OFF, NULL, &pMusicSound) );
SAFE_FMOD( m_pSystem->playSound(FMOD_CHANNEL_FREE, pMusicSound, false, &pMusicChannel) );[/code:32c7bzsx]
Thankful for answers.
- Pontus asked 9 years ago
[quote="mathew":27hhha0a]Hardware support is complete, it also uses software codecs (3.0 and higher) if the hardware one is in use. Supported formats are everything an AudioQueue supports, but the key formats are MP3, AAC and ALAC.
This feature is currently in test by our key iPhone partners and is scheduled for the next major release. When GDC is over we plan to roll out all our new stuff (iPhone HW support included) into our new development branch.[/quote:27hhha0a]
I made an Audio Queue codec before, and i found that FMOD is better than the iPhone’s hardware codec via Audio Queue. Here are my results for my app:
(app cpu %, sys cpu %, idle %)
1 mp3 alone with the hardware codec: 27 25 48
1 mp3 alone with fmod: 34 16 50
1 mp3 with the hardware codec and 1 with fmod: 44 24 32
2 mp3s with fmod: 50 16 34
Certainly, my app’s other functionalities are measured into this numbers as well, but you can see that FMOD is still 2% better. I wonder if you could make the hardware codec useful.
The FMOD hardware AudioQueue implementation is more performant than the FMOD software codec implementations. Also for 3.0+ devices, you can have multiple AudioQueue software codecs which are also more performant than their FMOD counterparts. Additionally the AudioQueue implementation also enables support for AAC and ALAC so it will definitely be beneficial.
everything is perfect with my Audio Queue codec now, except dead slow seeking in an MP3 file (1-2 seconds)!
This is what i do on the setposition callback:
- Calculate new packet number.
- AudioQueueStop(audioQueue, true);
- AudioQueueStart(audioQueue, NULL);
- Call the buffer-filling callback directly.
I’m sure your implementation doesn’t suffer from this, but how did you made it fast? AudioQueueStop/Start makes the whole process very slow.
We plan to implement hardware decoding via the AudioQueue offline decoder as an FMOD codec. There has been a few stalls getting this project started due to other higher priority commitments but we are still eager to get this done as soon as possible.
[quote="mathew":1zymu46y]The FMOD hardware AudioQueue implementation is more performant than the FMOD software codec implementations. Also for 3.0+ devices, you can have multiple AudioQueue software codecs which are also more performant than their FMOD counterparts. Additionally the AudioQueue implementation also enables support for AAC and ALAC so it will definitely be beneficial.[/quote:1zymu46y]
Are you sure you measure all CPU, not just the "user" part? Because all i see is a CPU loading shift from "user" (FMOD) to "system" (Audio Queue).
I checked many aspects of my implementation using Shark, Instruments etc., but all that CPU eating thing happens in Core Audio, not my code, and i couldn’t really optimize nothing (tried to adjust buffer sizes, etc.).
Or maybe you don’t use AudioFileReadPackets, but FMOD’s own? What’s the secret Sir?
It sounds to me like you are using the same method for implementing setPosition as us. As for performance issues, if you have any tips or tricks you would like to share we would be happy to review them for inclusion in FMOD.
Perhaps we should move this discussion to firstname.lastname@example.org?
[quote="mathew":1nrg4lu7]What method are you using to get the CPU usage results?
Our block alignment is 16384 bytes rounded down to ensure it’s a multiple of the bytes per frame size. Also yes, we are using AudioFileReadPackets.[/quote:1nrg4lu7]
I’m using top from the bash command line (the phone is jailbroken), it provides more precise results than Instruments.
Your block alignment is 16384 bytes rounded down to the frame size of the input file, the frame size of an MP3 for example?
Sorry, now i know. So you’ve 16384 rounded down to a multiple of the output bytes per frame, so it will be 16384 still for 16-bit stereo PCM.
I’ve 2 last optimization questions:
How long buffer size did you choose for packetsToRead from AudioFileReadPackets? 1 seconds, half second… ?
What’s the best format to convert to? I’m doing FMOD_SOUND_FORMAT_PCM16 (kLinearPCMFormatFlagIsPacked | kLinearPCMFormatFlagIsSignedInteger), but is it better if i choose PCMFLOAT?
I recently profiled my App that uses version FMOD 4.28.02.
And I’m really surprised by the CPU usage.
I didn’t remember having these numbers last time I checked it (with a 4.26 version).
I don’t remember changing anything on the data side or on my code.
Do you see anything I should look into ?
Please login first to submit.