1. 01 Oct, 2021 6 commits
    • Marijn Suijten's avatar
    • Marijn Suijten's avatar
      bluetooth: Use software volume for >100%, balance and finer control · b8c118f3
      Marijn Suijten authored
      This compensates discrepancies between requested volume and actual
      volume represented by the 127-step A2DP range or 15-step HSP/HFP range,
      including setting volume above 100% without any additional logic; the
      delta simply becomes larger.  The delta is calculated per channel
      against "mono" hardware volume on the remote to also take care of
      differences in balance.  The remote uses the maximum volume of all
      channels and software is used to attenuate below that (or above, if one
      or more channels are set above 100%).
      Note that this does _NOT_ take the actual volume on the remote into
      account yet! Most headphones don't use the full range, and instead round
      to the nearest multiple of some arbitrarily chosen step size.
      They do reply with this value, which we should consequently retrieve and
      deal with.
    • Marijn Suijten's avatar
      bluetooth: Handle muting over A2DP Absolute Volume · f0cd769b
      Marijn Suijten authored
      Muting is a special case that is explicit and separated from volume
      within PulseAudio, but merged together into a single variable over the
      A2DP AVRCP connection.
      Most devices report either 0 or 1 as their lowest volume.
      Note that capital Volume in the following paragraphs refer to the Volume
      property on org.bluez.MediaTransport1.
      This commit deals with the following cases:
      1. When the PA stream is muted, notify the peer by setting Volume to 0.
         While the stream is muted real_volume should _not_ be updated in the
         callback when Volume changes to <= 1, or unmuting will _not_ return
         to the original volume.
      2. When locally changing stream volume, and muting is enabled, do _not_
         send updates to the peer.  The peer should stick with Volume = 0.
      3. When locally changing stream volume (and sending that to the peer)
         any resulting updates on the Volume property should _not_ turn on
      4. When the peer changes Volume, turn off muting (if enabled) when
         Volume > 1.
      5. When the peer changes Volume, turn on muting when Volume <= 1.
      Such an implementation matches what happens on an Android device.
      Muting sets the shared volume to 0, and upping the volume on the peer
      (in case of headphones which usually only have up/down buttons) will set
      it a single increment above that.  Unmuting the stream from PA however
      will return the stream back to the original volume, and notify the peer
      of the same.
      The discrepancy between merged and separate muting+volume results in a
      conflict between point 3. and 5.: The peer (and/or dbus API) always
      responds with the Volume property changing after PA writes it.  If PA's
      stream volume is decreased to a point where the callback triggers with
      Volume <= 1 the stream is consequently muted, in accordance to point 5.
      This is especially problematic when decreasing the local volume too far
      (whether intentionally or not), as muting is not turned off by default
      when the stream volume is increased afterwards.
      This case is dealt with by preventing any Volume lower than 2 to be sent
      to the device at any given point.  Only the device itself can return a
      Volume lower than that to enable implicit muting.
      However, when point 5. happens, it is important to note that it can only
      be unmuted by explicitly unmuting the stream from PA, _or_ increasing
      the volume on the peer.
    • Marijn Suijten's avatar
      bluetooth/gst: Replace buffer accumulation in adapter with direct pull · ed5d6142
      Marijn Suijten authored
      Bluetooth codecs should always have fixed in/output and are hence able
      to have their results directly read from the codec, instead of
      accumulating in a buffer asynchronously that is subsequently only read
      in the transcode callback.  The Bluetooth backends calling encode/decode
      also expect these fixed buffer sizes.
    • Marijn Suijten's avatar
      bluetooth/gst: Use GStreamer synchronously within PA's IO thread · 5cb9afc5
      Marijn Suijten authored
      Handling multiple threads does not come without overhead, especially
      when the end-goal is to ping-pong them making the whole system run
      serially.  This patch rips out all that thread handling and instead
      "chains" buffers to be encoded/decoded directly into the pipeline,
      making them execute their work on the current thread.  The resulting
      buffer can be pulled out from appsink immediately without require extra
      locking and signalling.  While the overhead on modern systems is found
      to be negligible or unnoticable, code complexity of such locking and
      signalling systems is prevalent making it the main drive behind this
    • Chupligin Sergey's avatar
      Fix spelling of warning · 17a57378
      Chupligin Sergey authored
      Part-of: <pulseaudio/pulseaudio!639>
  2. 30 Sep, 2021 1 commit
  3. 27 Sep, 2021 1 commit
  4. 22 Sep, 2021 30 commits
  5. 20 Sep, 2021 1 commit
  6. 08 Sep, 2021 1 commit
    • Igor Kovalenko's avatar
      combine-sink: Add remix modarg · c94a3a9f
      Igor Kovalenko authored and PulseAudio Marge Bot's avatar PulseAudio Marge Bot committed
      When module-combine-sink is used to create virtual surround card it is expected
      that each slave channel receives data for exactly one combined sink channel.
      Currently this is not the case because module-combine-sink would follow
      core->disable_remixing setting. Usually this means that multiple channels of
      combined sink are getting remixed into slave channel, and there is no option to
      disable this behavior just for combined sink.
      Improve this by implementing "remix" modarg for module-combine-sink,
      default to original behavior (follow core->disable_remixing setting).
      Part-of: <pulseaudio/pulseaudio!627>