Apple

On Thu, Dec 5, 2013 at 2:18 PM, Beinan Li <email@hidden> wrote:

Thanks Aran for the clarification. Now that I understood it is by design, I'd like to raise some scenarios that may need attention or advice:

Say the app is a game with its built-in music and sound effects, but the player wants to listen to his own music for just two minutes and get back to the game later without taking the game to the background. When he pauses the music and gets back to the game, now he needs UI help to restart the game's audio due to the missing "back trip" from the interruption. This seems to be a major distraction without a smart UI design.

About the design against possible confusion, I do know that if the user locked the phone or switched to something else, the problem would disappear because we have to use app lifecycle to control audio (e.g., silence). The problem only happens when the app is in the foreground, which indicates that the user wants to return to the app soon.

If the app was foreground and remained so by the time the music pauses, I wonder how much more confusing it could be for the app to resume its audio playback than to throw complete silence at the user when he refocuses onto the app that was making sounds a minute ago. He then has to realize to pause the entire game and switch on music/SFX in the option menu three taps away...and back.

I sense that the design treats app audio as lower priority compared to the music app, possibly from the iPod tradition. For audio-centric apps, this one-way interruption could be problematic.

Is having the phone calls and alarms as the only "exceptions" a sonic sanitation measure? I'm curious because if there are two exceptions, why not just open that hook and let apps decide whether to implement the "back trip" or not?

I know all these are subjective so I'm just bringing it up for discussion. Hopefully in the end I'll be convinced and happily take it for granted.

Thanks,

Beinan

On Wed, Dec 4, 2013 at 8:15 PM, Aran Mulholland <email@hidden> wrote:

This is by design.

When I'm using a music app ("Acme Drum Machine") and then I want to listen to some music from my iTunes library I don't expect the music app ("Acme Drum Machine") to start making noise when I pause or stop my music. This would be confusing for users. Basically the user has just paused his music (maybe to talk to someone) and then noise continues to play in his ears. The only time I want "Acme Drum Machine" to make noise is when I instruct it to.

The only exception to this rule is if the user receives a phone call. When the phone call finishes the music (from the iTunes library or a third party app) will start playing again because at no time did the user pause or stop the audio.

Cheers

Aran

On Thu, Dec 5, 2013 at 10:09 AM, Beinan Li <email@hidden> wrote:

Hello CoreAudio,

While our app's audio is playing, if we play music from Music app using earbud remote-control's play/pause button, our registered interruption listener is called with interruption flag being kAudioSessionBeginInterruption (i.e., we entered audio interruption).

However, pressing the play/pause button again the music will pause, so we expect that the interruption ends at the point, but the interruption listener is not called.

This can be reproduced with the Xcode sample projects:

iPhoneMultichannelMixerTest and iPhoneMixerEQGraphTest.

Is this by design: no "end of interruption" signal from remote-control at all?

It is a big problem for us because there is no way to resume app's audio automatically when the Music app is paused.

Beinan

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden