Comment détecter quelque chose dans la prise casque d’un Mac?

Existe-t-il un moyen de détecter si quelque chose est branché sur la prise casque d’un Mac en utilisant c ou objective-c ?

Merci

Si vous souhaitez toujours vous plonger dans cette magie profonde et y toucher, je suis capable de construire quelque chose ensemble à partir du code que j’ai trouvé ici:

http://www.iphonedevsdk.com/forum/iphone-sdk-development/54013-hardware-volume-change-listener-callback.html

Vous souhaitez enregistrer une écoute sur AudioProperties et intercepter tous les messages concernant ‘kAudioSessionProperty_AudioRouteChange’. En utilisant la “raison” et le “nom”, vous pouvez parsingr pour rassembler ce qui s’est passé. Vous pouvez également en savoir plus à ce sujet ici:

http://developer.apple.com/library/ios/#DOCUMENTATION/AudioToolbox/Reference/AudioSessionServicesReference/Reference/reference.html

 // Registers this class as the delegate of the audio session. [[AVAudioSession sharedInstance] setDelegate: self]; // Use this code instead to allow the app sound to continue to play when the screen is locked. [[AVAudioSession sharedInstance] setCategory: AVAudioSessionCategoryPlayback error: nil]; // Registers the audio route change listener callback function AudioSessionAddPropertyListener (kAudioSessionProperty_AudioRouteChange, audioRouteChangeListenerCallback, self); 

Rappeler:

 void audioRouteChangeListenerCallback (void *inUserData, AudioSessionPropertyID inPropertyID, UInt32 inPropertyValueSize, const void *inPropertyValue ) { // ensure that this callback was invoked for a route change if (inPropertyID != kAudioSessionProperty_AudioRouteChange) return; { // Determines the reason for the route change, to ensure that it is not // because of a category change. CFDictionaryRef routeChangeDictionary = (CFDictionaryRef)inPropertyValue; CFNumberRef routeChangeReasonRef = (CFNumberRef)CFDictionaryGetValue (routeChangeDictionary, CFSTR (kAudioSession_AudioRouteChangeKey_Reason) ); SInt32 routeChangeReason; CFNumberGetValue (routeChangeReasonRef, kCFNumberSInt32Type, &routeChangeReason); if (routeChangeReason == kAudioSessionRouteChangeReason_OldDeviceUnavailable) { //Handle Headset Unplugged } else if (routeChangeReason == kAudioSessionRouteChangeReason_NewDeviceAvailable) { //Handle Headset plugged in } } } 

C’est l’une de «ces choses»: des choses que vous ne devriez jamais, jamais avoir besoin de faire ou de savoir. L’idée générale est que vous utilisez les API fournies pour la reproduction des sons et que le sous-système de son s’occupe du rest.

Si vous avez besoin d’une configuration spécifique, vous pouvez demander à l’utilisateur via une boîte de dialog de bien vouloir configurer son système de manière spécifique, mais c’est à peu près tout.

Edit: La raison en est que la programmation de pilotes en général et la programmation de sons en particulier constituent une magie profonde, et toute application qui tente de brouiller le matériel de la machine pour quelque raison que ce soit échoue généralement de façon spectaculaire, mais souvent assez subtile.

Sauf si vous développez des applications d’entreprise pour un ensemble de machines connu et fermé, ne faites jamais d’hypothèses sur le matériel de la machine: avant même de le savoir, le prochain modèle de l’iMac est livré sans prise analogique.

Et même si la prise analogique est présente et vide, le son peut être dirigé via une carte son secondaire, intégrée, PCI ou USB. Heck, il y a même des cartes son FireWire qui flottent, si la mémoire est bonne.

C’est une fonction cachée qui existe (ou pas) sur votre puce intégrée. Si le fabricant publie une API, vous pouvez la contrôler, sinon vous ne pouvez pas.