0
0

We want to use AudioSessionGetProperty to check if the user was playing any audio before our app started (so we mute our music and let theirs continue playing.) Currently, we’re doing so with this code:

[code:3tqfu1iq]if (noErr == AudioSessionInitialize(NULL, NULL, NULL, NULL)) {
UInt32 wasPlaying = 0;
UInt32 szWasPlaying = sizeof(wasPlaying);
if (noErr == AudioSessionGetProperty(kAudioSessionProperty_OtherAudioIsPlaying, &szWasPlaying, &wasPlaying)) {
wasPlayingOtherAudioAtLaunch = (wasPlaying != 0);
}
}[/code:3tqfu1iq]

In order for AudioSessionGetProperty to function correctly, AudioSessionInitialize must first be called. We can’t initialize FMOD until after we call AudioSessionGetProperty, because it changes which session mode we pass to FMOD_System_Init in the driver data. The code currently works without issue, but is there any reason why it might cause problems for FMOD? Do you consider it safe to use this code?[/code]

  • You must to post comments
0
0

No we do not consider this code safe.

FMOD must be the one that initializes the audio session because we need to register callbacks to handle interruptions like a phone call coming in.

The way to handle this situation depends on how you want your game to behave. If you want to always play your game music simply choose one of the session categories that prohibit mixing.

If you want to potentially let the user play iPod music you choose one of the categories that permit mixing, then query the value of the FMOD_IPHONE_EXTRADRIVERDATA member otherAudioPlaying. Using that value you can choose whether to mute your game music or not.

The otherAudioPlaying member is in 4.26.00 onwards, let me know if you have any issues using this method.

  • You must to post comments
0
0

Unfortunately, FMOD is a fairly heavy system, and we keep it unloaded when possible to free system resources (as well as tearing the whole thing down when receiving iPhone memory warnings.) It would be ideal if we could query kAudioSessionProperty_OtherAudioIsPlaying independently of having a full FMOD_SYSTEM object set up and running. Is there a way to query the otherAudioPlaying field, or access it in some other FMOD-safe way, before fully creating and initializing FMOD?

That is, could FMOD be modified to call AudioSessionInitialize() and remember that it called it, so that some function (e.g. FMOD_OtherAudioPlaying()) could call it too without requiring that FMOD_System_Create() and FMOD_System_Init() first be called?

(I hope I’m being clear here.)

  • You must to post comments
0
0

AudioSessionInitialise only needs to be called once, so if you init FMOD then close it the audio session remains initialized. You can make your OtherAudioIsPlaying calls after FMOD is shut down.

Also as a side note, we have a reduced version of FMOD with much of the stuff disabled to safe space, perhaps this would be useful to you. Is your primary concern the footprint of FMOD in memory?

  • You must to post comments
0
0

FMOD’s memory footprint is a bit of an issue, but if it’s been reduced then that’s good news. Do you have any particular metrics on how much it has been reduced?

  • You must to post comments
0
0

I did just some tests to see how much memory FMOD is using, so using ObjectAlloc in Instruments taking the difference in memory usage between before system create and then after system init.

From the vanilla PlaySound example I used setSoftwareFormat to drop the input channels down to 2, since the output is stereo it is unlikely you have greater than 2 channel input files. I also dropped the number of channels in init down to 16, depending on your app you can tweak this as appropriate, the same goes for setSoftwareChannels (I dropped that to 8).

With these changes the idle footprint of FMOD was 290KB. If you use the reduced version it was about 280KB. The main difference with the reduced version is the size of the lib though, i.e. normal lib is around 1.7MB, reduced is 1.3MB (900KB in our next release).

  • You must to post comments
0
0

Looking over our code and the FMOD headers, I see the current FMOD-safe way to get the value of kAudioSessionProperty_OtherAudioIsPlaying has a significant flaw.

The FMOD_IPHONE_EXTRADRIVERDATA structure is used to specify both the session category as well as the value of kAudioSessionProperty_OtherAudioIsPlaying. However, the latter is generally used to determine the former. If other audio is playing, apps will select FMOD_IPHONE_SESSIONCATEGORY_AMBIENTSOUND and not play their own music; otherwise, they will select FMOD_IPHONE_SESSIONCATEGORY_SOLOAMBIENTSOUND and play their own music (and prevent the user from starting his or her iPod library and making things all noisy, thus keeping the audio hardware from choking on two MP3s at once.)

In order to determine which session category to use, it is necessary to know the value of otherAudioPlaying before the driver data is set. It seems to me there needs to be some FMOD-safe way to query kAudioSessionProperty_OtherAudioIsPlaying before calling FMOD_System_Init().

On iPhone OS 3.0, the programmer can examine [MPMusicPlayerController iPodMusicPlayer].nowPlayingItem to see if the iPod app is active, but this is not an option on 2.2.1 or earlier; as well, it isn’t really meant for that purpose.

Perhaps a function could be declared in fmodiphone.h:

FMOD_RESULT F_API FMOD_iPhone_OtherAudioPlaying (FMOD_BOOL *outPlaying);

This function would call AudioSessionInitialize() on behalf of FMOD and set it up as FMOD expects, while also allowing the programmer to query kAudioSessionProperty_OtherAudioIsPlaying in time for it to be useful.

I repeat the suggestion because currently, FMOD crashes when initialized too soon (as detailed in the other thread I just created.) If the crash cannot be resolved, this would be another possible solution.

  • You must to post comments
0
0

In most cases people have just used a mixing audio session then used the otherAudioPlaying returned from init to default the music to on or off. There is no issue with two hardware decoders colliding since FMOD decodes all audio in software.

If you really want to force at category depending on the otherAudioPlaying flag you could always init twice.

Ideally we would like to provide a feature like what is available on Xbox360 where you put your music into a music channel group and it gets auto muted when the users plays dashboard (or ipod in our case) music. However a bug in the iPhone SDK is prevent this.

  • You must to post comments
Showing 7 results
Your Answer

Please first to submit.