1. 06 Apr, 2021 4 commits
  2. 05 Apr, 2021 21 commits
  3. 03 Apr, 2021 1 commit
    • Igor Kovalenko's avatar
      bluetooth: prioritize native backend HFP HF connection · 1f204a13
      Igor Kovalenko authored
      Bluez prepends newly registered profile to a list of supported profiles,
      and new peer profile connections are attempted in reverse order of profile
      Currently native backend would register HFP AG profile before HSP AG profile.
      When peer supports both HFP HF and HSP HS profiles, this registration order
      causes extra HSP HS connection attempt before native backend would reject it
      to make sure peer is reconnected with HFP HF profile.
      Reorder HSP AG profile registration before HFP AG to make sure peer supporting
      both profiles connects with HFP HF profile first.
      Part-of: <!534>
  4. 27 Mar, 2021 5 commits
  5. 26 Mar, 2021 1 commit
    • Marijn Suijten's avatar
      bluetooth: Only use hardware volume callbacks for peer attenuation · 02027518
      Marijn Suijten authored
      Setting these callbacks adds the HW_{VOLUME,MUTE}_CTRL flag even when
      PulseAudio is solely responsible for performing attenuation whilst only
      keeping the peer posted on changes.  For this case the hardware callback
      is not registered at all but instead a hook is attached to catch
      PA_CORE_HOOK_{SINK,SOURCE}_VOLUME_CHANGED.  Only when the peer performs
      attenuation (the peer is in HeadSet/HandsFree role) are the callbacks
      used, without touching PA software volume at all.  A future change could
      potentially use software volume to compensate for the extremely coarse
      16 steps of volume control in HSP and HFP, and to allow volume over
      Part-of: <!519>
  6. 25 Mar, 2021 1 commit
  7. 23 Mar, 2021 2 commits
  8. 17 Mar, 2021 1 commit
    • Marijn Suijten's avatar
      bluetooth: Set up hardware gain control if init volume is received late · 8db4dff2
      Marijn Suijten authored
      Originally written for A2DP this rework of that patch enables late-bound
      hardware volume control on HFP and HSP.  As per the specification the
      headphones (where gain control for both speaker and microphone could
      happen in hardware on the peer) are supposed to send initial values for
      these before the SCO connection is created; these `AT+VG[MS]` commands
      are also used to determine support for it.  PA uses this information in
      `add_{sink,source}` to attach hardware volume callbacks, _if_ it is
      supported.  Otherwise PA performs the attenuation in software.
      Unfortunately headphones like the WH-1000XM3's connect to A2DP
      initially and only send `AT+VGS` (microphone hardware gain is not
      supported) _during_ SCO connection when the user switches to the HFP
      profile afterwards; the callbacks set up dynamically in
      `rfcomm_io_callback` are written after the sink and source have been
      created (`add_{sink,source}`), leaving them without hardware volume
      callbacks and with software volume when adjusted on the PA side.  (The
      headphones can still send volume updates resulting in abrupt changes if
      software and peer volume differ.  Furthermore the same attenuation is
      applied twice - once in PA software, once on the peer).
      To solve this problem we simply check whether the callbacks have been
      attached whenever the peer sends a volume change, and if not attach the
      callbacks to the sink/source and reset software volume.
      Fixes: d510ddc7 ("bluetooth: Perform software attenuation until HF/HS reports gain control")
      Part-of: <pulseaudio/pulseaudio!528>
  9. 16 Mar, 2021 3 commits
  10. 15 Mar, 2021 1 commit
    • Marijn Suijten's avatar
      bluetooth: Generalize speaker/microphone naming to sink/source · d84ca030
      Marijn Suijten authored
      Sink and source naming is more generic when dealing with audio that is
      directional in the sense that it either goes to or comes from the other
      device, but not necessarily a microphone or speaker. A concrete example
      is the swapped meaning when the current device is in the HeadSet
      profile. The incoming audio can come from any source, not necessarily a
      microphone. Likewise, audio captured by the microphone of the headset is
      not necessarily played back by a speaker on the AG, it is merely acting
      as a sink for the data: further handling is irrelevant to the naming.
      Part-of: <pulseaudio/pulseaudio!521>