Re: iPhoneOS 3.1 and kAudioSessionProperty_OverrideCategoryEnableBluetoothInput
Re: iPhoneOS 3.1 and kAudioSessionProperty_OverrideCategoryEnableBluetoothInput
- Subject: Re: iPhoneOS 3.1 and kAudioSessionProperty_OverrideCategoryEnableBluetoothInput
- From: Greg Chapman <email@hidden>
- Date: Fri, 02 Oct 2009 17:44:25 -0700
On Oct 2, 2009, at 2:55 PM, Jiri Kral wrote:
Hi,
has anyone tried using the new
kAudioSessionProperty_OverrideCategoryEnableBluetoothInput property?
It seems to behave quite differently than the documentation says.
When I set it in my application after I made a call with the builtin
GSM phone app using the bluetooth, it switches both input (from the
headset microphone) and output to the bluetooth headset, while the
documentation says: "Use of this property doesn’t affect the audio
output route for the kAudioSessionCategory_PlayAndRecord category".
This is actually good, I don't see what good would it be to have an
input in the headset and output from the builtin speaker?
Yeah, that documentation is wrong. It affects both input and output.
And that's a good thing, as you say.
When I set this property after I make a GSM call using the iPhone
receiver, nothing happens at all. This is much worse. The bluetooth
headset remains silent and it's microphone doesn't work either. Still,
the AudioSessionSetProperty call returns 0 (no error)!!
The property only enables Bluetooth for that category (by default you
simply can't use BT to record), it does not select it for use.
Apps don't actually get to route audio wherever they want (not even
Apple apps!)... we (under the hood) send the audio where the user
wants it.
How do we know where the user wants it?
Well, we pay attention to the things the user did last that might
affect audio routing. For example:
1. If the user most recently plugged in a wired headset, that's where
the audio I/O goes.
2. If the user most recently pulled a phone call away from the
Bluetooth headset, that's where the audio _won't_ go. (and that's
what you did, if I understood you correctly)
This seems a little loopy when you first hear about it, but we
actually do a pretty consistent, predictable job of this.
So, the user is in control here. There is a gesture the user can make
to "jack in" a Bluetooth headset, but it's in a UI element that your
app might not currently have: the volume slider control. If there is
a connected BT device, there will be an extra button in that control
that will bring up an audio route picker, in which the user can select
the BT device (or deselect it), and we will interpret that the same
way we interpret in a jack-in or unjack of a wired headset. We'll
route audio there, or stop routing audio there.
My questions:
1) Is there a way to reliably switch the audio over to the bluetooth
headset?
Not from your code. But the user has a way in the UI you can bring up.
2) Is there a way to find out if there is any bluetooth headset
connected at all?
Not from your code. But the user will see it show up in the route
picker (and will see the route picker button show up, for that matter)
when the BT headset connects.
Greg
_______________________________________________
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