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"? 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. 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
