Apple’s documentation says that once an app joins a Push to Talk channel, pressing "play" on a headset should start recording. On my iPhone it doesn't. Both the M015 (our earbud) and AirPods send the press to Apple Music instead. The phone's own log says "No context for this command", then opens Music. So we ask Apple:
Sigh... So, the problem here is balancing the benefits of the basic behavior apps want against the problems that behavior then creates. On the benefit side, the basic behavior you want is for pushing the "play" button on your earbuds to start recording. At a hardware level, that means that a certain AVRCP command (basically "play") will trigger recording.
Unfortunately, that behavior comes with certain problems. The first thing to understand here is that, from the system side, it doesn't really "know" all that much about the controller it's interacting with. It has some basic hardware identification ("Name"/"Vendor"/"Model"/etc.) information but nothing about what "kind" of accessory something actually "is". So, as far as the system is concerned, the full range of audio hardware— headsets, speakers, speakerphones, car head units, etc.— all look basically "the same". Most critically, the Bluetooth market is SO diverse and broad that using something like a database to map specific accessories to "categories" isn't all that helpful, as even a very large database ends up leaving out a large number of accessories. Indeed, that approach is often counterproductive as the "gaps" in the database end up making the system look random/inconsistent instead of actually making it "better".
The second thing to understand is that many of those products have very longstanding behaviors which don't really "work" with the PushToTalk framework. The most obvious example is that virtually all car head units send a "play" command when the accessory connects. That lets your music start playing when you get into your car... but it also means that the PushToTalk framework would start recording every time the user turned their car on.
That last issue in particular is why the PTT framework doesn't just take over all remote events. A PTT app that WANTS to do this can do so by becoming the Now Playing app and processing the events itself (this is how PTT apps used to work), but the PTT framework currently chooses the "safer" route.
As an aside, if you want the PTT framework to support "full" seizure (meaning, it responds to all hardware events), then please file a bug on this and post the bug number back here.
What exactly has to be true for the earbud press to reach Push to Talk instead of Music?
My understanding is that we currently support:
-
Events from our own wired earbuds.
-
Telephony HID events. Typically these are USB headsets but, in theory, HID over Bluetooth should also work.
-
HFP (Handsfree Profile) events.
Note that HFP is what can make Bluetooth headset support seem somewhat erratic since, for example, most headset hardware can end recording even though it can't initiate it. What's actually going on here is that starting the recording switched the device into HFP, which the system then supported.
Does it work at all when nothing is playing?
Strictly speaking, what matters here is the state of the accessory itself, not what's happening in the audio system. However, the vast majority of headsets switch back to A2DP when an HFP session ends, which means the control stops working regardless of playback state.
Can one press start and the next press stop, or is it press-and-hold only?
This depends entirely on what the headset itself sends.
One thing to keep in mind here is that I'm only talking about the PushToTalk framework's built-in control support. Along with that direct support, PushToTalk apps can choose to implement their own hardware control support, either through Now Playing (see above) or by using CoreBluetooth to support proprietary PushToTalk control hardware.
Is a Bluetooth data signal from the earbud the only other way?
I'm not sure what you mean here.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
