0
0

Hi,
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

  • You must to post comments
0
0

[quote:3n3jngdx]I’m using top from the bash command line (the phone is jailbroken), it provides more precise results than Instruments. [/quote:3n3jngdx]
Ah ok, yeah the instruments method of getting CPU seems a bit imprecise. The FMOD CPU usage measure is good but it doesn’t take into account mediaserv.
[quote:3n3jngdx]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.[/quote:3n3jngdx]
That is correct, for 16bit stereo the size is the same, are just ensuring there is a whole number of frames in the buffer.
[quote:3n3jngdx]How long buffer size did you choose for packetsToRead from AudioFileReadPackets? 1 seconds, half second… ? [/quote:3n3jngdx]
As for read packets, we use 16k / max packet size, with a minimum of 2 packets.
[quote:3n3jngdx]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?[/quote:3n3jngdx]
The best format to output in is 16bit as you are doing.

  • You must to post comments
0
0

Nothing has changed recently with the MP3 codec, it is decoded in software and one of the more expensive formats to choose. If the usage is too high for your app I would recommend switching to a cheaper format like ADPCM or wait until March for the hardware decoder support.

  • You must to post comments
0
0

[quote:14ndfha2]As for read packets, we use 16k / max packet size, with a minimum of 2 packets.[/quote:14ndfha2]

For many MP3s the max packet size is 1052, so MAX(2, 16384/1052) = approx 15.5 seconds?

  • You must to post comments
0
0

The key difference between using the native iPhone API for MP3 playback and FMOD is you are decoding the MP3 at runtime in software with FMOD, where as the iPhone API uses the hardware decoder.

We do plan to add support for the hardware decoder at some point but it has the pretty big limitation of only being able to decode one sound at a time, and that is only if the iPod isn’t already playing.

20% sounds a bit excessive to me actually, our benchmarks show for a mono MP3 the cost is about 5.6% so stereo would be around 11% as recorded by System::getCPUUsage.

  • You must to post comments
0
0

Hi Mathew,

I was wondering if there’s any news regarding the mp3 hardware decoding ?
Also I assume that fmod should run on ipad ?

Thanks !

  • You must to post comments
0
0

AudioFileReadPackets asks for how many packets to read, we do 16k / maxPacketSize, this can give numbers like 15 for how many packets to read at a time. This is not 15 seconds though, it’s around 0.4 seconds if the sample rate were 44100Hz.

  • You must to post comments
0
0

Thank you for your answer.

That is to bad that FMOD don’t uses the hardware decoder.

The issue with only decode one sound at a time, is not a problem for us
because we only want to play one mp3 file at a time.

20% is not an exaggeration. This was a result of a test on a iPhone 3G. Test on a iPod 2G resulted in 12%. Results may differ 5% +/- depending on the update rate of the application.

For the time being, we will use the iPhone AudioToolbox to play our music and hoping for an updated FMOD version with iPhone hardware support.

Thanks.
– Pontus

  • You must to post comments
0
0

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.

  • You must to post comments
0
0

Looking forward to this update! Any info on ETA would be awesome!

  • You must to post comments
0
0

I am hoping to get some time during the next month to add support for the iPhone hardware decoder.

  • You must to post comments
0
0

[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.

  • You must to post comments
0
0

We plan to roll this out in our next release (the new development branch). Our current target is the start of next month.

  • You must to post comments
0
0

Hi Mathew,

is there any news regarding a hardware support for the MP3 playback ?
Do you plan to use AudioQueue to achieve it ?

Many thanks !

  • You must to post comments
0
0

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.

  • You must to post comments
0
0

Hi Mathew,

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:

  1. Calculate new packet number.
  2. AudioQueueStop(audioQueue, true);
  3. AudioQueueStart(audioQueue, NULL);
  4. 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.

Gábor

  • You must to post comments
0
0

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.

  • You must to post comments
0
0

[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?

  • You must to post comments
0
0

I just tested 4.31 with your Audio Queue codec version.

My Audio Queue codec performs better (less CPU), and yours suffers from the seeking issue as well… :-)

Do you make any effort to solve this? We can join our forces if you like.

  • You must to post comments
0
0

Hi Matthew,

thanks for the reply, can’t wait to see this working !

Thanks

  • You must to post comments
0
0

I left blockalign on 4 which was my mistake.

I’ve set it to 4096, and Audio Queue is 5% less overall CPU now than FMOD, per track.

What’s is your choice of blockalign?

  • You must to post comments
Showing 1 - 20 of 29 results
Your Answer

Please first to submit.