1. 21 Feb, 2022 7 commits
    • Marijn Suijten's avatar
      bluetooth: Handle muting over A2DP Absolute Volume · 3953d445
      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
         muting.
      
      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.
      3953d445
    • Marijn Suijten's avatar
      bluetooth/gst: Timestamp encoding buffers according to PA clock · 5af2afba
      Marijn Suijten authored and Arun Raghavan's avatar Arun Raghavan committed
      Commit c6d6ca54 ("bluetooth/gst: Replace buffer accumulation in adapter
      with direct pull") removed the `timestamp` parameter from GStreamer
      transcoders due to being unused, but these should instead be propagated
      to the GStreamer encoding buffers.
      
      Part-of: <!494>
      5af2afba
    • Marijn Suijten's avatar
      bluetooth/gst: Replace buffer accumulation in adapter with direct pull · 5f37914e
      Marijn Suijten authored and Arun Raghavan's avatar Arun Raghavan committed
      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.
      
      Part-of: <pulseaudio/pulseaudio!494>
      5f37914e
    • Marijn Suijten's avatar
      bluetooth/gst: Use GStreamer synchronously within PA's IO thread · 201dc654
      Marijn Suijten authored and Arun Raghavan's avatar Arun Raghavan committed
      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
      refactor.
      
      Part-of: <pulseaudio/pulseaudio!494>
      201dc654
    • Arun Raghavan's avatar
      build-sys: Bump libpulse soversion for 16.0 · 62deab21
      Arun Raghavan authored and PulseAudio Marge Bot's avatar PulseAudio Marge Bot committed
      Part-of: <pulseaudio/pulseaudio!690>
      62deab21
    • Sanchayan Maity's avatar
      bluetooth: Rename rtp_sbc_payload to rtp_payload · 516c691f
      Sanchayan Maity authored
      Now that we use RTP payload structure for LDAC as well, rename
      rtp_sbc_payload to rtp_payload. PipeWire also uses the same naming.
      
      Part-of: <!689>
      516c691f
    • Sanchayan Maity's avatar
      bluetooth: ldac: Fix RTP payloading of encoded packet · 9f0a18b2
      Sanchayan Maity authored
      Drop rtpldacpay and payload the LDAC encoded output manually in the
      RTP header.
      
      The RTP payload seems to be required as it carries the frame count
      information. Right now, rtpldacpay does not add this so construct
      the RTP header and payload manually.
      
      Strangely some devices like Shanling MP4 and Sony XM3 would still
      work without this while some like the Sony XM4 does not.
      
      Part-of: <pulseaudio/pulseaudio!689>
      9f0a18b2
  2. 26 Jan, 2022 2 commits
  3. 25 Jan, 2022 1 commit
  4. 11 Jan, 2022 2 commits
  5. 10 Jan, 2022 3 commits
  6. 08 Jan, 2022 2 commits
  7. 05 Jan, 2022 1 commit
  8. 29 Dec, 2021 2 commits
  9. 18 Dec, 2021 1 commit
  10. 17 Dec, 2021 1 commit
  11. 16 Dec, 2021 18 commits