• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
deactivating audio session and [[UIApplication sharedApplication] endReceivingRemoteControlEvents];
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

deactivating audio session and [[UIApplication sharedApplication] endReceivingRemoteControlEvents];


  • Subject: deactivating audio session and [[UIApplication sharedApplication] endReceivingRemoteControlEvents];
  • From: George Kola <email@hidden>
  • Date: Wed, 28 May 2014 01:19:23 -0700

We have a walkie-talkie iOS app.  We want to get headset button presses and we use  “Remote control events” as described in https://developer.apple.com/library/ios/documentation/EventHandling/Conceptual/EventHandlingiPhoneOS/Remote-ControlEvents/Remote-ControlEvents.html

         We have a slight variation in that  we call 

[[UIApplication sharedApplication] endReceivingRemoteControlEvents];
    
        before we deactivate the audio session. The snippet is as follows and it runs on the main queue  (got using dispatch_get_main_queue())


[[UIApplication sharedApplication] endReceivingRemoteControlEvents];

 NSError *theError;
 if (unlikely(NO == [[AVAudioSession sharedInstance] setActive:NO withOptions:AVAudioSessionSetActiveOptionNotifyOthersOnDeactivation error:&theError]))
 {
       NSLog(@"deactivating the audio session failed: %@", theError);
 } else {
       NSLog(@"Deactivated Audio Session");
 }



 The issue is that sometimes, the deactivation of our audio session does not properly notify other apps — for example, the music player does not resume music play back. It happens only around 2 out of 5 times. We found that if we did the following, it works all the time

[[UIApplication sharedApplication] endReceivingRemoteControlEvents];
 
    void (^deactivateAudioSessionBlock)() = ^(void){
  
        NSError *theError;
        if (unlikely(NO == [[AVAudioSession sharedInstance] setActive:NO withOptions:AVAudioSessionSetActiveOptionNotifyOthersOnDeactivation error:&theError]))
        {
            NSLog(@"deactivating the audio session failed: %@", theError);
        } else {
            NSLog(@"Deactivated Audio Session");
        }

        

     
    };

   

   dispatch_time_t popTime = dispatch_time(DISPATCH_TIME_NOW, (int64_t)(50 * NSEC_PER_MSEC));
   dispatch_after(popTime, dispatch_get_main_queue(), deactivateAudioSessionBlock);




             Basically, adding a 50 ms delay between calling [[UIApplication sharedApplication] endReceivingRemoteControlEvents]; and de-activating audio session ensures that music player resumes. 

             We want to understand why the 50 ms delays makes it work and want to know what is the recommended to make this code robust so that we always notify other music apps (the 50 ms is a hack that we got through experimentation)



Thanks,
George
 _______________________________________________
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

  • Prev by Date: Re: iOS - Receiving MIDI Event from MusicPlayer
  • Next by Date: How to handle "mode" parameters that fix the value of other parameters?
  • Previous by thread: outCurrentSampleInTimeLine confusion
  • Next by thread: How to handle "mode" parameters that fix the value of other parameters?
  • Index(es):
    • Date
    • Thread