[pulseaudio-discuss] Headset support

[David Woodhouse]

On Wed, 2018-04-04 at 18:53 +0200, Pali Rohár wrote:
> On Wednesday 04 April 2018 16:47:57 David Woodhouse wrote:
> > I've now counted three types of headset control that we should support,
> > ideally through a consistent interface.
> > 
> > 
> >  • The first is Bluetooth HFP/HSP for which support is already present 
> >    and just needs to be connected up.
> > 
> >  • Second is the USB HID devices, including most "Skype for Business"
> >    certified headsets. I have a Pidgin plugin which drives these 
> >    directly, but it would be better for PulseAudio to open the HID 
> >    device for itself and for the controls to be associated with the
> >    specific hardware.
> > 
> >  • Third is the Android/etc. 3.5mm jack where button presses are
> >    implemented as short-circuit or specific resistances from the mic
> >    pin to ground:
> >    https://source.android.com/devices/accessories/headset/plug-headset-spec
> >    The Linux kernel has support for these (at least for a few codec 
> >    chips), and they appear as events on an input device along with the 
> >    jack insertion/removal events. Which I note we also don't support in
> >    PA yet? Although there were patches in 2011 at 
> >    https://www.mail-archive.com/pulseaudio-discuss@mail.0pointer.de/msg09830.html
> > 
> > 
> > Are there any more?

Thanks.

> Nokia ECI headsets - 3.5mm jack with bi-directional ECI bus on MIC bias.
> In most cases those headsets contain buttons, but ECI bus supports also
> some memory read/write operations. But IIRC it is not possible to use
> them with ordinary sound cards (activating MIC bias is too slow for ECI)
> and Nokia implemented ECI protocol in their phones at ASIC level, some
> translation of ECI to I2C. ECI protocol itself is undocumented, but I
> saw some images from oscilloscope from which protocol could be decoded.

That one I think is a kernel problem. If implemented in Linux, it would
presumably end up appearing to userspace just the same way as #3 above,
with a separate input device emitting events for the button presses.
Userspace doesn't necessarily need to care, right?

> Other Nokia headsets (non-ECI) - again 3.5mm jack, but supports only one
> button press. Maybe similar to your "third" one.

Yeah, probably. And either way, I think it's still the kernel's problem
to work out the hardware details and just emit events.

> Bluetooth A2DP with AVRCP - but this should be already supported.

With the possible exception of volume control, I suspect AVRCP support
is mostly outside the scope of PulseAudio. For volume controls we might
want to ensure that they affect the *correct* device volume, in the
A2DP+AVRCP case where there clearly is a "correct" device. But not the
case of a pure AVRCP remote control.

We have this problem with volume control on USB headsets already. They
provide a HID device which emits KEY_VOLUMEUP / KEY_VOLUMEDOWN events.
So right now as I'm listening to a podcast on my headset, if I press a
volume button not only does it immediately change the headset volume,
but the system *also* sees that "keypress" and adjusts the volume of
the laptop's built-in speakers too. Which is wrong. That volume
keypress should have been handled in the context of the device it came
from. We *do* get that right for HFP, I believe.

Other than volume control, the main common headset control features
are:

 • on/off hook.
 • mute (mic).
 • ring
 • Additional feature button(s)

At least for the SfB-certified USB headsets, the hook and mute controls
need management. When the mute/hook buttons are pressed, userspace has
to update the mute/hook status on the device accordingly, otherwise
things don't work right (subsequent presses are ignored, etc.).

I suspect the correct approach is revive the patches which opened the
input device for the jack, then do something similar to open the HID
dev associated with a USB headset. Then to define hook/mute/ring
properties and get signals working on the PA side, and hook that up to
at least the GStreamer pulses{rc,ink} elements.

Then applications like Pidgin and Ekiga can do a saner version of the
headset management, through GStreamer.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5213 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20180406/903904bb/attachment.bin>