Demo Gotcha

[markNZed]

Hi,

The demo was not speaking out loud, and not making any noise. I thought it was broken.

I’ll share this experience in the hope it may save you some time.

I had my iPhone paired with a bluetooth headset some time ago. I don’t use the headset.

It seems that OpenEars picks up that bluetooth headset and reroutes the audio output. This is the case for the demo and my code using OpenEars. I don’t think it should do that unless we ask it to :)

Still a great framework!

Mark

[Halle Winkler]

Welcome Mark,

Thanks for the feedback. I’m not quite sure I agree with the premise yet but I’m happy to talk it through and appreciate the input.

It sounds like there is a bluetooth headset which is both paired and powered on, is that correct? My expectation as a developer is that in this scenario, the user has actively chosen BT as their audio route (OpenEars always has to make some assumptions about what the default route should be and they are based on probable usage cases), so if I want it instead to ignore the BT device I will override the route code. Is it a common scenario for your users that they have a BT device paired and powered on but wouldn’t expect it to be the in/out audio route? Anyone else wants to share their own usage cases that I might be overlooking here, please go ahead; this is an interesting question that I hadn’t realized might be an issue.

[markNZed]

Hi Halle,

The bluetooth device was on and it had been paired in the past. But the audio was not being routed to it in other apps or my app. I had forgotten that it was paired.

Other apps would route sound to the speaker. The iPhone phone app pops up with an option to choose the headset or not.

I don’t think this is a common scenario. But maybe OpenEars should allow for the app to decide if the bluetooth is used or not because it seems many apps ignore the bluetooth output.

In my use case I probably need to change my app to behave like OpenEars :)

[Halle Winkler]

In my use case I probably need to change my app to behave like OpenEars :)

Heh :) . This is definitely an maximally-interesting API design question. One of the design goals of OpenEars is for it to generally do the right thing without configuring or selecting every option in play (there are so many areas of potential optional behavior in the whole SDK that it could become development-thwartingly twiddly for the use cases of 95% of developers if I went with the wall-o-switches approach, and impossible to give good support for), and then to operate on the basis that developers who want to customize and add new hooks can dig in and alter the source however they need to. But that also means that there should be occasional discussions about whether a default expectation is correct.

IMO, apps that positively route audio to a route other than a paired and powered-on BT audio device are probably making the wrong call because the user has done enough to indicate their intentions with the BT device when they physically switched it on, which in my understanding of user expectations says more than tapping a screen button when the devices in question have a constrained battery life. Apple’s approach covers all the bases and is clearly safest.

But the shortcoming of having the discussion here is that the only information that matters is the ultimate user experience. Do you have people you can test with and get feedback from about what they are intending when they have a BT device attached and are using your app? I find that there are sometimes surprises about what is important or an obvious default to people using the apps and what isn’t.

[markNZed]

Hi Halle,

There will be some beta testing in the field of one app we are developing that integrates OpenEars and will use headsets. The app I was working on is the HiLO Lens app – that is already available in the App Store. I’ve not had feedback on behavior with headsets yet for HiLO Lens.

My use case is control of the camera. In that scenario I think your defaults make sense.

If open ears is going to be an ideal citizen then it probably needs to check what the audio setup is prior to re-routing it. So if the app is using the headset then use the headset but if the headset is not being used then don’t use it. I’m trying to think of an example – how about bluetooth audio in a car – we want the phone calls routed to the car audio but not confirmation noises made by an app.

Your approach of KISS and let the hackers make changes is a good one I think. Keeping the entry barrier as low as possible is more important.

Mark

[markNZed]

PS the HiLO Lens app is free.

[Halle Winkler]

Thanks for the considered feedback. I think you make a good point and I’ll keep it in mind as I’m making some audio session tweaks in upcoming versions. Congrats on the HiLO app being out — feel free to share a link to the app if you’d like!

[Author]

Posts