1. 23 Apr, 2021 1 commit
  2. 22 Apr, 2021 5 commits
    • Marijn Suijten's avatar
      bluetooth: Delay A2DP Absolute Volume setup until property is available · 9a6ca4d4
      Marijn Suijten authored
      The Volume property on org.bluez.MediaTransport1 is required to utilize
      Absolute Volume, but it will only become availabe if the peer device
      supports the feature.  This happens asynchronously somewhere after the
      transport itself has been acquired, after which the callbacks are
      attached and software volume is reset.
      To prevent race conditions availability of the property is also checked
      on startup through a "Get" call.
    • Marijn Suijten's avatar
      bluetooth: Report a2dp_source volume changes to the source device · 9297bde1
      Marijn Suijten authored
      Write the current volume to the `Volume` DBus property to keep the
      volume on the remote in sync.  Without this the remote device shows the
      wrong volume, and any attempts to change it will cause an unexpected
      jump when the local volume has also been adjusted.
      Thanks to prior investments to improve volume synchronization, setting
      up callbacks and sending initial volume to the peer for HFP/HSP
      implementing this feature is as easy as unconditionally assigning a
      valid function to `set_source_volume`.  `source_setup_volume_callback`
      is already responsible for attaching a `SOURCE_VOLUME_CHANGED` hook and
      sending initial (restored) volume to the peer (signifying support for
      Absolute Volume - if not derived from the presence of FEATURE_CATEGORY_2
      on the profile yet).
    • Marijn Suijten's avatar
      bluetooth: Synchronize AVRCP Absolute Volume with A2DP sink · 534a80a5
      Marijn Suijten authored
      Like the previous commit this handles `Volume` property changes but
      applies them to an A2DP sink instead of source stream.  As mentioned in
      the AVRCP spec v1.6.2 §5.8 the rendering device (A2DP sink) is
      responsible for performing volume attenuation meaning PulseAudio should
      pass through audio as-is without performing any attenuation in SW.
      Setting a valid pointer to `set_sink_volume` and returning `true` from
      `should_attenuate_volume` attaches a hardware callback to `pa_sink` such
      that no volume attenuation is performed anymore.
      In addition to receiving volume change notifications it is also possible
      to control remote volume by writing a new value to the DBus property.
      This is especially useful when playing back to in-ear audio devices
      which usually lack physical buttons to adjust the final volume on the
      While software volume (used before this patch) is generally fine it is
      annoying to crank it up all the way to 100% when a previous connection
      to a different device left saved volume on the peer at a low volume.
      Providing this bidirectional synchronization is most natural to users
      who wish to use physical controls on their headphones, are used to this
      from their smartphone, or aforementioned volume mismatches where both PA
      as source and the peer as sink/rendering device are performing
    • Marijn Suijten's avatar
      bluetooth: Update source software volume on AVRCP SetAbsoluteVolume · 4e8c7fe4
      Marijn Suijten authored
      The A2DP spec mandates that the audio rendering device - the device
      receiving audio, in our case a `pa_source` - is responsible for
      performing attenuation:
      AVRCP v1.6.2, §5.8:
          The SetAbsoluteVolume command is used to set an absolute volume to be used by the rendering device.
      BlueZ models this call as a change of the `Volume` property on the
      `org.bluez.MediaTransport1` interface.  Supporting Absolute Volume is
      optional but BlueZ unconditionally reports feature category 2 in its
      profile, mandating support.  Hence remote devices (ie. a phone) playing
      back audio to a machine running PulseAudio assume volume is to be
      changed through SetAbsoluteVolume, without performing any local
      Future changes will implement this feature the other way around: setting
      an initial value for the `Volume` property as well as propagating
      `pa_source` volume changes back to the peer.
    • Marijn Suijten's avatar
      bluetooth: Move HSP_MAX_GAIN to header for reuse in n_volume_steps · 118ffca8
      Marijn Suijten authored
      Instead of hardcoding the number `16`, use `HSP_MAX_GAIN + 1`.
  3. 20 Apr, 2021 1 commit
    • Georg Chini's avatar
      stream-restore: Fix use of uninitialized variable · 1c1d0c78
      Georg Chini authored
      The variable card_name in sink_input_preferred_sink_changed_cb and
      source_output_preferred_source_changed_cb could be used uninitialized,
      which leads to invalid database entries.
      This patch fixes the problem.
      Part-of: <!543>
  4. 19 Apr, 2021 6 commits
  5. 16 Apr, 2021 1 commit
    • Igor Kovalenko's avatar
      bluetooth: disable HSP HS profile by default · fec9eb17
      Igor Kovalenko authored
      A few headsets have issues if HFP HF profile connection is attempted before
      HSP HS profile connection is closed. Looks like this could happen because
      bluez bluetoothd alows to make simultaneous HSP HS and HFP HF peer connections.
      One of affected headsets is WH-1000XM2
      Until we find out how to prevent simultaneous HSP HS and HFP HF connections,
      when native backend has HFP HF profile enabled (this is the default) do disable
      HSP HS completely unless user explicitly request it via discovery modarg.
      Do this by adding module-bluetooth-discover arg enable_native_hsp_hs,
      default to inverse of enable_native_hfp_hf.
      Part-of: <!538>
  6. 14 Apr, 2021 1 commit
  7. 09 Apr, 2021 1 commit
  8. 05 Apr, 2021 21 commits
  9. 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>
  10. 27 Mar, 2021 2 commits