Detecting the iPhone's Ring / Silent / Mute switch using AVAudioPlayer not working?

I've tried using these methods in an attempt to detect that the Ring/Silent switch is active or not:

How to programmatically sense the iPhone mute switch?

AVAudioSession category not working as documentation dictates

But on my iPhone 4, the "state" value is always "Speaker" (and the length value returned by CFStringGetLength(state) is always 7). Has anyone used this method successfully? If so, on what kind of device and SDK version?

I'm calling it li开发者_运维技巧ke so:

- (BOOL)deviceIsSilenced {
    CFStringRef state;
    UInt32 propertySize = sizeof(CFStringRef);
    OSStatus audioStatus = AudioSessionGetProperty(kAudioSessionProperty_AudioRoute, &propertySize, &state);
    if (audioStatus == kAudioSessionNoError) {
        NSLog(@"audio route: %@", state) // "Speaker" regardless of silent switch setting, but "Headphone" when my headphones are plugged in
        return (CFStringGetLength(state) <= 0);
    }
    return NO;
}

-(BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {

    AVAudioSession *audioSession = [AVAudioSession sharedInstance];
    audioSession.delegate = self;
    [audioSession setCategory:AVAudioSessionCategoryAmbient error:nil];
    [audioSession setActive:YES error:nil];
    NSLog(@"muted? %i", [self deviceIsSilenced]);
    ...
}

I was thinking maybe some other (more accurate) kAudioSessionProperty event is fired when the physical switch on the phone is ... switched. Anyone have any ideas?

By the way, I'm using the AVAudioSessionCategoryAmbient category with my [AVAudioSession sharedInstance].

Update: I've also tried using different audio categories, and a handful of other audio session properties, none seem to fire when muting/unmuting the switch. :(

Jan. 1, 2014 Update: It's a bit of a hack, and I encountered a crash while multitasking w/ it on my iPhone 5S, but the SoundSwitch library linked in the new accepted answer is the way to go if you want to detect the silent switch. It even works in iOS 7.

Well I found the answer thanks to someone from the Developer Forums, and you guys aren't gonna like it!

I've had a response from Apple on this.

They've said they don't and never have provided a method for detecting hardware mute switch and don't intend to do so.

:(

IMO there is definitely value in detecting the silent switch and notifying the user in case they've forgotten it was on... I've had people complain that they don't have any sound and the silent switch was the reason! Oh well.

PS: If you would like Apple to add this feature (and of course you do!) please file a new "Enhancement" bug report for "iPhone SDK" at http://bugreport.apple.com/

Update: While there is still no official way to check the status of the mute switch, there's a workaround/library called "SoundSwitch" that seems to do the trick. Check out the new accepted answer for the link.

"However, if someone could show us how to use this AudioSessionProperty_AudioRouteDescription, the bounty is rightfully his."

Well, just NSLog() the result and you get

routes: {
    "RouteDetailedDescription_Inputs" =     (
    );
    "RouteDetailedDescription_Outputs" =     (
                {
            "RouteDetailedDescription_PortType" = Speaker;
        }
    );
}

Unfortunately, I get that identical result on an iPad2/OS 5.0 both muted and unmuted. So it appears to be functionally equivalent to kAudioSessionProperty_AudioRoute, no joy there.

Looking on the developer boards finds that this is a frequently encountered problem, summed up best with

"I reported this issue with rdar://9781189 back in July and the issue is still present in the GM."

So yeah ... sure looks like you're SOL with this in 5.0.

ADDENDUM:

"But how about that CFDictionary that you are logging. How can I access the "RouteDetailedDescription_PortType" key?"

Toll free bridging is your friend.

  CFDictionaryRef asCFType = nil;
  UInt32 dataSize = sizeof(asCFType);
  AudioSessionGetProperty(kAudioSessionProperty_AudioRouteDescription, &dataSize, &asCFType);
  NSDictionary *easyPeasy = (NSDictionary *)asCFType;
  NSDictionary *firstOutput = (NSDictionary *)[[easyPeasy valueForKey:@"RouteDetailedDescription_Outputs"] objectAtIndex:0];
  NSString *portType = (NSString *)[firstOutput valueForKey:@"RouteDetailedDescription_PortType"];
  NSLog(@"first output port type is: %@!", portType);

produces

first output port type is: Speaker!

Many common CFTypes are bridged to more convenient types.

http://developer.apple.com/library/ios/#documentation/CoreFoundation/Conceptual/CFDesignConcepts/Articles/tollFreeBridgedTypes.html

Now, it takes a little bit of practice to guess correctly what magic incantation casts will get something useful out of a dictionary as above. A class dump helper along these lines will help you get up to speed with that:

  - (void)whatsInThis:(CFDictionaryRef)thingy
  {
     NSDictionary *dict = (NSDictionary *)thingy;
     for (NSString *key in dict.allKeys)
     {
        id value = [dict valueForKey:key];
        NSLog(@"key: %@ value type %@", key, [value class]);
        if ([value isKindOfClass:[NSArray class]])
        {
           NSArray *array = (NSArray *)value;
           for (id item in array)
           {
              NSLog(@" -- object type %@", [item class]);
              if ([item isKindOfClass:[NSDictionary class]])
                 [self whatsInThis:item];
           }
        }
     }
  }

which for our dictionary at hand produces (adding indentation for clarity)

key: RouteDetailedDescription_Inputs value type __NSCFArray
key: RouteDetailedDescription_Outputs value type __NSCFArray
  -- object type __NSCFDictionary
    key: RouteDetailedDescription_PortType value type __NSCFString

which lets you know for sure what you could have deduced from the original log, knowing that NSLog displays arrays within ( ) and dictionaries within { } so the correct casts were eminently guessable. But some CFType structures are rather harder to parse than that.

I went through this VSSilentSwitch library.
Didn't work for me (doesn't work when you start actually using audio).
I was thinking on how he did it, and then realised that the audio completion call is being called almost as soon as the sound begins playing when we're silent.
To be a bit more specific:
System sounds being played using AudioServicesPlaySystemSound will complete playback as soon as it started.
Of course, this will only work on audio categories that respect the silent switch (the default AVAudioSessionCategoryAmbient respects it).
So the trick is to create a system sound, preferably of a silent sound, and keep playing it over and over again, while checking the time it took from playback to completion (install a completion procedure using AudioServicesAddSystemSoundCompletion).
If the completion proc is called very soon (allow some threshold) - it means the silent switch is on.
This trick has many caveats, the biggest one being the fact that it won't work on all audio categories.
If your app plays audio in the background - make sure you stop this test while in the background or your app will run forever in the background (and will be rejected by apple, too).

Try inserting this line above your call to AudioSessionGetProperty inside deviceIsSilenced

AudioSessionInitialize(NULL, NULL, NULL, NULL);

Should then start returning empty string when switch is down (although will show Headphone and some other states if BT headset or accessory connected for example).

FWIW I don't believe there is anything in public API that will fire when actual switch is moved.

I think you've got the wrong impression. A route is where it's going. You want to know the volume level. Use kAudioSessionProperty_CurrentHardwareOutputVolume

Ok, After following kAudioSessionProperty_AudioRoute using CMD + click, I found this :(

/*!
 @enum           AudioSession audio categories states
 @abstract       Deprecated AudioSession properties
 @constant       kAudioSessionProperty_AudioRoute 
 Deprecated in iOS 5.0; Use kAudioSessionProperty_AudioRouteDescription 
 */
enum {
    kAudioSessionProperty_AudioRoute                            = 'rout',   // CFStringRef      (get only)        
};

turns out we have to use kAudioSessionProperty_AudioRouteDescription, but this guy returns a CFDictionaryRef or something, and I have absolutely no idea how to deal with it....

I made this an answer in case no one shows us how to use kAudioSessionProperty_AudioRouteDescription, where I will try to accept my answer...

However, if someone could show us how to use this kAudioSessionProperty_AudioRouteDescription, the bounty is rightfully his.

edit:

Clearly, this is an iOS 5 problem. I didn't state this earlier because it looked too obvious, but then I thought it might not be as obvious to search engines .. if you get what I mean.

So, iOS 5 is not working with the silent/mute switch on the iPhone because of the referred deprecated value.

Found this library http://www.verietassoftware.com/index.php?option=com_content&view=article&id=27&Itemid=115

Would Apple allow that stuff? It is a 500Kb library doing some black magic with audio & phone settings