Re: iPhoneOS 3.1 and kAudioSessionProperty_OverrideCategoryEnableBluetoothInput
Re: iPhoneOS 3.1 and kAudioSessionProperty_OverrideCategoryEnableBluetoothInput
- Subject: Re: iPhoneOS 3.1 and kAudioSessionProperty_OverrideCategoryEnableBluetoothInput
- From: Jiri Kral <email@hidden>
- Date: Sun, 4 Oct 2009 12:52:17 +0200
Hi Greg,
thanks for the pointer to the volume slider, that was very useful.
What you write about iPhone OS managing the routes for the user sounds
great, but the user should still be able to switch the routes if he
wants to. There is currently no easy way to let him do it:
Bluetooth route can be turned on only via the route picker, the
speakerphone can be selected as an override (both iPod and iPhone) or
from the route picker (iPhone only). Besides, you write that the route
picker button appears only when BT is available, so it can't be used
as a general way to switch to speakerphone even on iPhone.
On the other hand, the user can still choose "speakerphone" from the
route picker on the iPhone, which creates two ways how to enable the
speakerphone. If the application wants to display some indicator
whether speakerphone is off/on, it's not possible to detect it (at
least not reliably)
At least, this is what I've figured out from playing with the API on
iPhone and iPod touch, please correct me if I'm missing something. I
believe that letting the user choose between BT,receiver and
speakerphone, with an indicator which one is active should be a bit
easier :)
Kind Regards
Jiri
On Sat, Oct 3, 2009 at 2:44 AM, Greg Chapman <email@hidden> wrote:
>
> 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
>
_______________________________________________
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