Hello, > -----Original Message----- > From: Pauli Virtanen <pav@xxxxxx> > Sent: Thursday, July 25, 2024 7:46 PM > To: Vlad Pruteanu <vlad.pruteanu@xxxxxxx>; linux- > bluetooth@xxxxxxxxxxxxxxx > Cc: Mihai-Octavian Urzica <mihai-octavian.urzica@xxxxxxx>; Iulia Tanasescu > <iulia.tanasescu@xxxxxxx>; Andrei Istodorescu > <andrei.istodorescu@xxxxxxx>; luiz.dentz@xxxxxxxxx > Subject: [EXT] Re: [PATCH BlueZ v2 1/5] doc/media: Add 'broadcasting' state > and 'Select' method > > Caution: This is an external email. Please take care when clicking links or > opening attachments. When in doubt, report the message using the 'Report > this email' button > > > Hi, > > to, 2024-07-25 kello 14:58 +0300, Vlad Pruteanu kirjoitti: > > This adds a new state for transports created by the Broadcast > > Sink. Such transports will remain in the 'idle' state until the > > user calls 'Select' on them, at which point they will be moved to > > 'broadcasting'. This allows the user to select the desired BIS as > > the audio server automatically acquires transports that are in this > > state. > > --- > > doc/org.bluez.MediaTransport.rst | 16 +++++++++++++++- > > 1 file changed, 15 insertions(+), 1 deletion(-) > > > > diff --git a/doc/org.bluez.MediaTransport.rst > b/doc/org.bluez.MediaTransport.rst > > index 6e95df8f2..47346d36b 100644 > > --- a/doc/org.bluez.MediaTransport.rst > > +++ b/doc/org.bluez.MediaTransport.rst > > @@ -7,7 +7,7 @@ BlueZ D-Bus MediaTransport API documentation > > -------------------------------------------- > > > > :Version: BlueZ > > -:Date: September 2023 > > +:Date: July 2024 > > :Manual section: 5 > > :Manual group: Linux System Administration > > > > @@ -51,6 +51,18 @@ void Release() > > > > Releases file descriptor. > > > > +void Select() > > +`````````````` > > + > > + Applicable only for transports created by a broadcast sink. This moves > > + the transport from 'idle' to 'broadcasting'. Since the audio server > > + automatically acquires transports that are in this state, the user can > > + thus select which BISes he wishes to sync to. > > + > > + Possible Errors: > > + > > + :org.bluez.Error.NotAuthorized: > > Should there also be Unselect() that forces the transport back to > "idle"? > Yes we also need this command. I will send an updated patch to also include this method. > IIRC, BlueZ as A2DP Sink/ACP behaves like that --- when remote INT > stops audio stream the transport goes back to "idle". So it would be > similar, with the difference that a local application --- instead of > the remote side --- is controlling whether the stream is "playing". > > I guess the design question here is whether local apps shall to talk to > BlueZ or the sound server to enable specific audio streams. > I think that at least for discovering Broadcast Sources local apps should talk to BlueZ, since, after all, it's a matter of scanning for a Bluetooth device that is advertising and acting according to the profile specification. To me, the process is similar to A2DP, without the actual connection process, and since for A2DP the local apps first talk to BlueZ, I believe that this should be the case here as well. > Having the "enable" flag either in BlueZ or on audio server side is > possible, esp. if it is question of transport acquire. > > As audio server, we could e.g. expose it as the device "on/off" profile > state, which user can turn on/off e.g. in pavucontrol. > > *** > > Note that the current Pipewire BAP Broadcast behavior I think is work > in progress. Acquiring the transport on PENDING I think is maybe > accidental --- it is using the BAP Unicast Server code path, and in one > of the bcast sink patches from NXP I see there seems to be intent to > use BAP Unicast Client like behavior, but probably it's not quite right > if you see the acquire-on-pending behavior. > > (As "server" Pipewire will expose audio streams similarly as > application audio streams, and by default direct them to available > audio speakers. As "client" Pipewire exposes the audio streams as > virtual microphone devices, which the user can manually record from or > link to speakers.) > > > + > > Properties > > ---------- > > > > @@ -84,6 +96,8 @@ string State [readonly] > > > > :"idle": not streaming > > :"pending": streaming but not acquired > > + :"broadcasting": streaming but not acquired, applicable only for > transports > > + created by a broadcast sink > > :"active": streaming and acquired > > > > uint16 Delay [readwrite, optional] > > -- > Pauli Virtanen Regards, Vlad
