The iOS application is a Central Manager connected to a Bluetooth Low Energy (BLE) accessory that utilizes the Hands-Free Profile (HFP).
When the application plays a notification tone (using AVAudioPlayer or System Sounds), the audio is incorrectly routed to the device's internal speaker instead of the active HFP headset.
How do we programmatically ensure that these notification tones are automatically and reliably routed to the connected HFP headset
Can we achieve playing notification tones through an accessory using HFP profile using an SCO connection on iOS
How do we programmatically ensure that these notification tones are automatically and reliably routed to the connected HFP headset
Take a look at "Routing audio to specific devices in multidevice sessions", which covers the direct issue of audio routing.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
Application is using AVAudioSessionCategoryPlayAndRecord category and AVAudioSessionCategoryOptionAllowBluetooth Option to play the Notification tone. But as per the Apple documentation AVAudioSessionCategoryOptionAllowBluetooth Option is Deprecated and the Document suggests to use AVAudioSessionCategoryOptionAllowBluetoothHFP as alternative. But AVAudioSessionCategoryOptionAllowBluetoothHFP Option is not defined in AVAudioSessionCategoryOptions
Is there any option to use as alternative of AVAudioSessionCategoryOptionAllowBluetooth option?
Application is using AVAudioSessionCategoryPlayAndRecord category and
How are you doing this? The audio system should not be allowing PlayAndRecord to directly activate in a background app.
But AVAudioSessionCategoryOptionAllowBluetoothHFP Option is not defined in AVAudioSessionCategoryOptions
What do you mean? It's right here.
Is there any option to use as alternative of AVAudioSessionCategoryOptionAllowBluetooth option?
No, but that's because AVAudioSessionCategoryOptionAllowBluetooth and AVAudioSessionCategoryOptionAllowBluetoothHFP are exactly the same thing. From AVAudioSessionTypes.h, after you remove the availability markings:
/// Deprecated - please see ``AVAudioSessionCategoryOptionAllowBluetoothHFP``
AVAudioSessionCategoryOptionAllowBluetooth = 0x4,
...
/// - Other categories:
/// AllowBluetoothHFP defaults to false and cannot be changed. Enabling Bluetooth for input in
/// these categories is not allowed.
AVAudioSessionCategoryOptionAllowBluetoothHFP = 0x4,
In other words, AVAudioSessionCategoryOptionAllowBluetoothHFP is a "rename" of AVAudioSessionCategoryOptionAllowBluetooth which was actually introduced to clarify that the value "0x4" actually "does".
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
How are you doing this? The audio system should not be allowing PlayAndRecord to directly activate in a background app.
For Notification Tones Audio session category is configured to AVAudioSessionCategoryPlayAndRecord with VoiceChat mode and AllowBluetooth option Tones play using system audio services without an active audio session No background audio session activation occurs for notification tones
For Notification Tones, Audio session category is configured to AVAudioSessionCategoryPlayAndRecord with VoiceChat mode and AllowBluetooth option. Tones play using system audio services without an active audio session. No background audio session activation occurs for notification tones.
Are you talking about using AudioServicesPlayAlertSound()/AudioServicesPlaySystemSound()?
If so, then the answer here is basically "no, you can't change any of the details of how those APIs behave". Both of those APIs work by shifting the actual playback out of process, instead of having "your" app directly play the audio. This allows them to be used in apps that don't have ANY audio configuration at all, as well as in contexts that would otherwise be complex/problematic. For example, it lets apps with arbitrarily complex and configurable audio configuration play alert sounds without having to figure out how to mix and route that alert sound with their own dynamic configuration.
It's true that AudioServicesPlayAlertSound() modifies its behavior based on your session configuration:
"iPhone—plays the specified sound. If the user has configured the Settings application for vibration on ring, also invokes vibration. However, the device does not vibrate if your app’s audio session is configured with the playAndRecord or record audio session category. This ensures that vibration doesn’t interfere with audio recording. For an explanation of audio session categories, see Categories Express Audio Roles."
...but what's actually going on here is that the function is checking your app’s current configuration and then tweaking the IPC message it sends requesting playback. Note that the fact it only plays audio files, as well as all of the other listed restrictions, actually comes from the fact that the playback engine is intentionally quite limited. It's designed to very quickly play alert sounds and nothing else.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware