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] ea6b63: profiles/audio/bass: Use BASS_Modify_Source when a...
Date: Thu, 11 Jun 2026 13:02:26 -0700	[thread overview]
Message-ID: <bluez/bluez/push/refs/heads/master/5d836f-40f2e3@github.com> (raw)

  Branch: refs/heads/master
  Home:   https://github.com/bluez/bluez
  Commit: ea6b63562d9d249b5925d09813aa01510123aae8
      https://github.com/bluez/bluez/commit/ea6b63562d9d249b5925d09813aa01510123aae8
  Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
  Date:   2026-06-10 (Wed, 10 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: 590aae8b695082185b2354e9f194078804fd9f2b
      https://github.com/bluez/bluez/commit/590aae8b695082185b2354e9f194078804fd9f2b
  Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
  Date:   2026-06-10 (Wed, 10 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: 5b0c20727569e0ad6fee2c7d92dd375fa0fb45b1
      https://github.com/bluez/bluez/commit/5b0c20727569e0ad6fee2c7d92dd375fa0fb45b1
  Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
  Date:   2026-06-10 (Wed, 10 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: 40f2e34b373944cf8142154881ce69f92c2be68d
      https://github.com/bluez/bluez/commit/40f2e34b373944cf8142154881ce69f92c2be68d
  Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
  Date:   2026-06-10 (Wed, 10 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/5d836f1c697c...40f2e34b3739

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

                 reply	other threads:[~2026-06-11 20:02 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/master/5d836f-40f2e3@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