Hi Luiz & al.,
ke, 2024-03-27 kello 12:50 -0400, Luiz Augusto von Dentz kirjoitti:
> On Wed, Mar 27, 2024 at 12:10 PM Iulia Tanasescu
> <iulia.tanasescu@xxxxxxx> wrote:
> >
> > This separates the iso_defer_accept function into dedicated ones for
> > unicast/broadcast, since the flow is different for each scenario:
> > For unicast, POLLOUT is checked on socket before calling read and
> > adding a G_IO_OUT watch. Checking for POLLOUT is not necessary for
> > broadcast, since currently this event is never generated on the
> > child socket. Instead, G_IO_IN is generated after BIG sync is
> > established and a BIS socket is ready to be accepted.
>
> @Pauli Virtanen Is this inline with TX Timestamping though? Or that
> only cares for POLLERR?
AFAICS this won't interact with TX timestamping. The timestamping only
cares about MSG_ERRQUEUE which is not touched here, and also the setup
here seems to concern what happens before user sends payloads, so
before there is going to be any timestamps.
> Also it would be great to know what are the plans of PW with respect
> to broadcast, I was thinking something like this:
>
> 1. Broadcast Source: Have some dedicated card that can be configured
> via configuration file or a dedicated app that performs the
> configuration which can then select what streams shall be broadcasted,
> since broadcasting things like system audio notifications probably
> doesn't make much sense.
> 2. Broadcast Sink: This shall be a little bit easier since we now
> enumerate the BASE found over the air, so it should work very closely
> to unicast, but perhaps you may also want to start a scan session
> while the card selection dialog is open so the user don't need to use
> yet another app to trigger it, or perhaps this should really be done
> at Bluetooth system settings that way PW don't show any Broadcast Sink
> until the user selects it at Bluetooth APP, this way we don't clutter
> PW interface with unsynchronized Broadcast Sinks. Note that in the
> future we are going to remove the step of creating a MediaEndpoint for
> Sinks since they are already configured over the air they shall appear
> as MediaTransports ready to be Acquired.
I've been waiting for the BlueZ side of it to settle down a bit. (I
note the BlueZ broadcast API is not documented, would be great if the
.rst docs would be updated too in the patches.) It would also be great
if there is some way to test all this locally, we've merged patches
from Silviu for broadcast sink, but I have myself only looked that it
should be OK in theory.
For Broadcast Source:
The plan here would be to add first some support that we can create and
destroy broadcast source MediaEndpoints on the fly, and then wire it up
to the runtime setting system we have, so user can create and remove
endpoints without having to restart daemons to reload configs.
Generally they would appear to user applications in similar way as
network audio sinks, there's established way how all this goes.
The fact that it has to be via the same DBus connection as the rest is
a bit inconvenient, but can be dealt with.
Ideally the BlueZ DBus API would be such that there could also be a
dedicated "broadcast" application that can send streams, without
needing to interact with the sound server, and also allowing a sound
server to be running its own broadcast sources if any simultaneously.
For Broadcast Sink:
We are going to expose whatever we see over the DBus API to the user as
audio sources, which can be connected where they want to, and will be
acquired when connected.
For controlling the scanning of the broadcast streams, and which
streams are going to be synced to: It feels a bit orthogonal to the job
of a sound server. We could in principle do it. The BT Controller would
appear a sound card object, and it would have additional properties
that would list the available streams, and one poke e.g. with
Pipewire's command line tools to sync to specific streams.
This would be inventing an API to do something that might in principle
also be DBus API in BlueZ.
I guess a question for both source and sink is whether the sound server
should do the whole thing, or only be responsible for the routing of
audio, with things like configuring BASE or selecting which streams to
sync being an orthogonal DBus API (which could then be controlled by
the sound server, or by a dedicated app which could then either
implement its own audio transports or leave it the audio transport part
to the sound server).
>
> > ---
> > tools/iso-tester.c | 45 +++++++++++++++++++++++++++++++++++----------
> > 1 file changed, 35 insertions(+), 10 deletions(-)
> >
> > diff --git a/tools/iso-tester.c b/tools/iso-tester.c
> > index 1864b9e9d..60afef301 100644
> > --- a/tools/iso-tester.c
> > +++ b/tools/iso-tester.c
> > @@ -4,7 +4,7 @@
> > * BlueZ - Bluetooth protocol stack for Linux
> > *
> > * Copyright (C) 2022 Intel Corporation.
> > - * Copyright 2023 NXP
> > + * Copyright 2023-2024 NXP
> > *
> > */
> >
> > @@ -489,6 +489,8 @@ struct iso_client_data {
> > bool pa_bind;
> > };
> >
> > +typedef bool (*iso_defer_accept_t)(struct test_data *data, GIOChannel *io);
> > +
> > static void mgmt_debug(const char *str, void *user_data)
> > {
> > const char *prefix = user_data;
> > @@ -2582,11 +2584,10 @@ static void setup_listen(struct test_data *data, uint8_t num, GIOFunc func)
> > }
> > }
> >
> > -static bool iso_defer_accept(struct test_data *data, GIOChannel *io)
> > +static bool iso_defer_accept_bcast(struct test_data *data, GIOChannel *io)
> > {
> > int sk;
> > char c;
> > - struct pollfd pfd;
> > const struct iso_client_data *isodata = data->test_data;
> > struct sockaddr_iso *addr = NULL;
> >
> > @@ -2610,6 +2611,31 @@ static bool iso_defer_accept(struct test_data *data, GIOChannel *io)
> > free(addr);
> > }
> >
> > + if (read(sk, &c, 1) < 0) {
> > + tester_warn("read: %s (%d)", strerror(errno), errno);
> > + return false;
> > + }
> > +
> > + tester_print("Accept deferred setup");
> > +
> > + data->io_queue = queue_new();
> > + if (data->io_queue)
> > + queue_push_tail(data->io_queue, io);
> > +
> > + data->io_id[0] = g_io_add_watch(io, G_IO_IN,
> > + iso_accept_cb, NULL);
> > +
> > + return true;
> > +}
> > +
> > +static bool iso_defer_accept_ucast(struct test_data *data, GIOChannel *io)
> > +{
> > + int sk;
> > + char c;
> > + struct pollfd pfd;
> > +
> > + sk = g_io_channel_unix_get_fd(io);
> > +
> > memset(&pfd, 0, sizeof(pfd));
> > pfd.fd = sk;
> > pfd.events = POLLOUT;
> > @@ -2632,12 +2658,8 @@ static bool iso_defer_accept(struct test_data *data, GIOChannel *io)
> > if (data->io_queue)
> > queue_push_tail(data->io_queue, io);
> >
> > - if (isodata->bcast)
> > - data->io_id[0] = g_io_add_watch(io, G_IO_IN,
> > - iso_accept_cb, NULL);
> > - else
> > - data->io_id[0] = g_io_add_watch(io, G_IO_OUT,
> > - iso_connect_cb, NULL);
> > + data->io_id[0] = g_io_add_watch(io, G_IO_OUT,
> > + iso_connect_cb, NULL);
> >
> > return true;
> > }
> > @@ -2648,6 +2670,9 @@ static gboolean iso_accept_cb(GIOChannel *io, GIOCondition cond,
> > struct test_data *data = tester_get_data();
> > const struct iso_client_data *isodata = data->test_data;
> > int sk, new_sk;
> > + iso_defer_accept_t iso_accept = isodata->bcast ?
> > + iso_defer_accept_bcast :
> > + iso_defer_accept_ucast;
> >
> > data->io_id[0] = 0;
> >
> > @@ -2676,7 +2701,7 @@ static gboolean iso_accept_cb(GIOChannel *io, GIOCondition cond,
> > return false;
> > }
> >
> > - if (!iso_defer_accept(data, io)) {
> > + if (!iso_accept(data, io)) {
> > tester_warn("Unable to accept deferred setup");
> > tester_test_failed();
> > }
> > --
> > 2.39.2
> >
>
>
--
Pauli Virtanen
