Linux bluetooth development
 help / color / mirror / Atom feed
From: Luiz Augusto von Dentz <noreply@github.com>
To: linux-bluetooth@vger.kernel.org
Subject: [bluez/bluez] b5b40a: profiles/audio/bass: Use BASS_Modify_Source when a...
Date: Thu, 11 Jun 2026 10:53:52 -0700	[thread overview]
Message-ID: <bluez/bluez/push/refs/heads/1110215/000000-ca320e@github.com> (raw)

  Branch: refs/heads/1110215
  Home:   https://github.com/bluez/bluez
  Commit: b5b40a4bd3dd23a5569c616ebaf14126881b7ed1
      https://github.com/bluez/bluez/commit/b5b40a4bd3dd23a5569c616ebaf14126881b7ed1
  Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
  Date:   2026-06-11 (Thu, 11 Jun 2026)

  Changed paths:
    M profiles/audio/bass.c

  Log Message:
  -----------
  profiles/audio/bass: Use BASS_Modify_Source when assistant is active

When a MediaAssistant is already active (streaming), a subsequent Push
should send Modify Source with PA_SYNC_NO_SYNC and bis_sync=0 to
remove the broadcast source, rather than adding a duplicate source.

Split push() into push_add_src() and push_mod_src() helpers. The push
dispatcher checks the assistant state: ACTIVE non-local assistants and
LOCAL assistants with a tracked source entry both route to
push_mod_src, while all others proceed with push_add_src.

Add per-device source tracking for LOCAL assistants via a bass_src
struct (keyed by bt_bass pointer) stored in a per-assistant srcs
queue. This is needed because LOCAL assistants never change state, so
we cannot rely on the state machine alone to detect active sources.

Also fix the bass_src_changed BID filter: the previous check rejected
non-local assistants when BID was zero, but this incorrectly excluded
LOCAL assistants in REQUESTING state whose BID happens to be non-zero.
Change to reject assistants whose own BID is non-zero when the
notification BID is zero, which correctly matches local streams.


  Commit: e7d235efae7ed33f0ae0df91205277668181e0f4
      https://github.com/bluez/bluez/commit/e7d235efae7ed33f0ae0df91205277668181e0f4
  Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
  Date:   2026-06-11 (Thu, 11 Jun 2026)

  Changed paths:
    M profiles/audio/bass.c
    M src/shared/bass.c

  Log Message:
  -----------
  profiles/audio/bass: Handle PA_SYNC_NO_SYNC in handle_mod_src_req

When the delegator receives a Modify Source operation with pa_sync set
to PA_SYNC_NO_SYNC while already synchronized to PA, release all
setups instead of updating BIS sync which would not apply the
requested termination.

Also reset the encryption state to no encryption when the last BIS
index is cleared from a subgroup, so subsequent source additions
start with a clean encryption state.


  Commit: ef38d6371550e7596888e8198d328c802520bd18
      https://github.com/bluez/bluez/commit/ef38d6371550e7596888e8198d328c802520bd18
  Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
  Date:   2026-06-11 (Thu, 11 Jun 2026)

  Changed paths:
    M profiles/audio/bass.c

  Log Message:
  -----------
  profiles/audio/bass: Fix delegator reprobing after disconnect

delegator_disconnect left the old delegator in the delegators queue
after calling device_remove_profile. When a new delegator was created
for the same device (e.g. on a subsequent Add Source after Modify
Source removal), delegator_attach would find the stale entry and
return early, leaving the new delegator without a service. This
caused the "Unable to probe service" error and prevented the BASS
bcode exchange from working on reconnection.

Fix by removing the delegator from the queue, clearing service user
data, and calling delegator_free before disconnecting the service
and removing the profile. This also fixes a potential use-after-free
where delegator_disconnect accessed dg fields after device_remove_profile
could trigger delegator_detach -> delegator_free through the
bap_detached callback chain.

Also add validation in bass_req_bcode to detect and discard invalid
(all-zeros) broadcast codes that may have been stored from a previous
connection.


  Commit: ca320ea1e889ef325c64aaf9d41e32acdc7285d0
      https://github.com/bluez/bluez/commit/ca320ea1e889ef325c64aaf9d41e32acdc7285d0
  Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
  Date:   2026-06-11 (Thu, 11 Jun 2026)

  Changed paths:
    M doc/org.bluez.MediaAssistant.rst

  Log Message:
  -----------
  doc: Document Push behavior when MediaAssistant is active

Document that calling Push on an assistant already in active state uses
BASS_Modify_Source to update the existing source rather than adding a
new one.


Compare: https://github.com/bluez/bluez/compare/b5b40a4bd3dd%5E...ca320ea1e889

To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications

                 reply	other threads:[~2026-06-11 17:53 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bluez/bluez/push/refs/heads/1110215/000000-ca320e@github.com \
    --to=noreply@github.com \
    --cc=linux-bluetooth@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox