[pulseaudio-discuss] Headset support

[Pali Rohár]

On Friday 06 April 2018 10:20:42 David Woodhouse wrote:
> 
> 
> 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?

I would stick with fact that it is currently unsupported. I can imagine
fully software implementation in userspace e.g. very good sound card
where sound software would do sampling of microphone input and would do
whole decoding.

But in any case (once support will be there) it results in input device
and it would have exactly same problems and you wrote for USB headsets
below.

> > 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.

Example is Nokia N900. Here kernel creates one input device and send
BTN_something event when button is pressed. There is just one button and
what pressing it means is up to the userspace. It can be used e.g. for
accepting voice call or acts as play/pause...

> > 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.

Yes, I agree.

> 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.

This opens question about another problem: Who, how and when should
handle events from input devices? Integrated PS/2 keyboard on laptop is also
input device, external USB (or PS/2) keyboard on desktop is also input
device. And they could have also MIC_MUTE or MUTE buttons. Should these
buttons mute all sound cards? Or only those which are "integrated" (e.g.
not bluetooth headsets)? And who should handle these mute buttons?
Pulseaudio? Desktop hotkey daemon (e.g. KDE has own)? Or some new daemon
for these actions? Because currently e.g. KDE already handles mute
buttons/keys by its own.

I agree with you, that mic mute button on USB/bluetooth headset should
mute just microphone on that headset.

-- 
Pali Rohár
pali.rohar at gmail.com