bluez: dbus method call for switching endpoint

bluez: dbus method call for switching endpoint

[Pali Rohár]

Hi!

I prepared WIP patch for pulseaudio which adds support for A2DP aptX
codec (using LGPL libopenaptx library) but there is a one big problem.

https://patchwork.freedesktop.org/patch/236801/
https://github.com/pali/libopenaptx

bluez dbus API does not provide a way to switch from one codec to
another once A2DP connection is established.

And to have support for more codecs in pulseaudio (e.g. both SBC and
aptX) it is needed to export for each codec own endpoint.

I was told that for new connections bluez choose first registered
endpoint and therefore also codec. But when connection is initiated by
A2DP device itself, then codec is chosen randomly. And once connection
is active there is no way to change codec.

Therefore client application (like pulseaudio) have no control on codec
selection, nor it cannot change codes from one to other.

So for supporting more then one codec in pulseaudio, which means
anything different as mandatory SBC, it is needed that bluez exports
some dbus API for changing currently selected codec.

Can you extend bluez daemon for this support?

Also I have an another question, how to get (via dbus API) list of all
supported codecs by particular A2DP device? This is needed e.g. in GUI
applications for selecting which codec to use for headset device. And
select menu should contain only supported codecs.

-- 
Pali Rohár
pali.rohar@gmail.com

Re: bluez: dbus method call for switching endpoint

[Luiz Augusto von Dentz]

Hi Pali,

On Wed, Jul 11, 2018 at 11:23 AM, Pali Roh=C3=A1r <pali.rohar@gmail.com> wr=
ote:
> Hi!
>
> I prepared WIP patch for pulseaudio which adds support for A2DP aptX
> codec (using LGPL libopenaptx library) but there is a one big problem.
>
> https://patchwork.freedesktop.org/patch/236801/
> https://github.com/pali/libopenaptx
>
> bluez dbus API does not provide a way to switch from one codec to
> another once A2DP connection is established.
>
> And to have support for more codecs in pulseaudio (e.g. both SBC and
> aptX) it is needed to export for each codec own endpoint.
>
> I was told that for new connections bluez choose first registered
> endpoint and therefore also codec. But when connection is initiated by
> A2DP device itself, then codec is chosen randomly. And once connection
> is active there is no way to change codec.
>
> Therefore client application (like pulseaudio) have no control on codec
> selection, nor it cannot change codes from one to other.
>
> So for supporting more then one codec in pulseaudio, which means
> anything different as mandatory SBC, it is needed that bluez exports
> some dbus API for changing currently selected codec.
>
> Can you extend bluez daemon for this support?
>
> Also I have an another question, how to get (via dbus API) list of all
> supported codecs by particular A2DP device? This is needed e.g. in GUI
> applications for selecting which codec to use for headset device. And
> select menu should contain only supported codecs.

One way to solve all of these is that we would expose the remote
endpoints using MediaEndpoint1, though only SelectConfiguration would
be really useful here and that doesn't contain the remote capabilities
that probably should be made into properties, along with codec type
and uuid.

Note all of this is only useful as far as manually selecting goes
since I don't think it would be a good idea to torn down streams just
because the codec was not the best one as that may cause the whole
link to be disconnected. Besides a good headset would probably
remember what codec you selected the last time and just connect with
it, this btw is what I would do when operating as a sink.

--=20
Luiz Augusto von Dentz

Re: bluez: dbus method call for switching endpoint

[Pali Rohár]

On Wednesday 11 July 2018 16:27:07 Luiz Augusto von Dentz wrote:
> One way to solve all of these is that we would expose the remote
> endpoints using MediaEndpoint1

So client application (like pulseadio) would see list of remote
endpoints (one for each codec) and choose one for connection?

Looks like this should solve this problem.

> though only SelectConfiguration would
> be really useful here and that doesn't contain the remote capabilities
> that probably should be made into properties, along with codec type
> and uuid.

Remote capabilities are needed. And for codec type == vendor it is needed
to know also vendor id and codec id.

> Besides a good headset would probably
> remember what codec you selected the last time and just connect with
> it, this btw is what I would do when operating as a sink.

I hope that Linux would support also not-so-good headsets.

Anyway, dual booting between systems which support different set of
codecs makes those "good headset" with remember support just
"no-so-good" one.

-- 
Pali Rohár
pali.rohar@gmail.com

Re: bluez: dbus method call for switching endpoint

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 1406 bytes --]

On Wednesday 11 July 2018 16:45:01 Pali Rohár wrote:
> On Wednesday 11 July 2018 16:27:07 Luiz Augusto von Dentz wrote:
> > One way to solve all of these is that we would expose the remote
> > endpoints using MediaEndpoint1
> 
> So client application (like pulseadio) would see list of remote
> endpoints (one for each codec) and choose one for connection?
> 
> Looks like this should solve this problem.

Are there any progress on such API in bluez?

On pulseaudio mailing list other people proposed patches for other A2DP
codecs and basically bluez API for choosing A2DP codec is still missing
part...

> > though only SelectConfiguration would
> > be really useful here and that doesn't contain the remote capabilities
> > that probably should be made into properties, along with codec type
> > and uuid.
> 
> Remote capabilities are needed. And for codec type == vendor it is needed
> to know also vendor id and codec id.
> 
> > Besides a good headset would probably
> > remember what codec you selected the last time and just connect with
> > it, this btw is what I would do when operating as a sink.
> 
> I hope that Linux would support also not-so-good headsets.
> 
> Anyway, dual booting between systems which support different set of
> codecs makes those "good headset" with remember support just
> "no-so-good" one.
> 

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: bluez: dbus method call for switching endpoint

[Luiz Augusto von Dentz]

Hi Pali,

On Sat, Dec 15, 2018 at 5:29 PM Pali Rohár <pali.rohar@gmail.com> wrote:
>
> On Wednesday 11 July 2018 16:45:01 Pali Rohár wrote:
> > On Wednesday 11 July 2018 16:27:07 Luiz Augusto von Dentz wrote:
> > > One way to solve all of these is that we would expose the remote
> > > endpoints using MediaEndpoint1
> >
> > So client application (like pulseadio) would see list of remote
> > endpoints (one for each codec) and choose one for connection?
> >
> > Looks like this should solve this problem.
>
> Are there any progress on such API in bluez?
>
> On pulseaudio mailing list other people proposed patches for other A2DP
> codecs and basically bluez API for choosing A2DP codec is still missing
> part...

Im currenlty on vacation but will try to find time for that, that said
that shouldn't stop us to include support for other codecs, the last
set seems to have some sort of priority for ordering the registration
of the codecs.

> > > though only SelectConfiguration would
> > > be really useful here and that doesn't contain the remote capabilities
> > > that probably should be made into properties, along with codec type
> > > and uuid.
> >
> > Remote capabilities are needed. And for codec type == vendor it is needed
> > to know also vendor id and codec id.
> >
> > > Besides a good headset would probably
> > > remember what codec you selected the last time and just connect with
> > > it, this btw is what I would do when operating as a sink.
> >
> > I hope that Linux would support also not-so-good headsets.
> >
> > Anyway, dual booting between systems which support different set of
> > codecs makes those "good headset" with remember support just
> > "no-so-good" one.
> >
>
> --
> Pali Rohár
> pali.rohar@gmail.com



-- 
Luiz Augusto von Dentz

Re: bluez: dbus method call for switching endpoint

[Pasi Kärkkäinen]

Hi Luiz,

On Tue, Dec 18, 2018 at 01:02:39PM -0300, Luiz Augusto von Dentz wrote:
> Hi Pali,
> 
> On Sat, Dec 15, 2018 at 5:29 PM Pali Rohár <pali.rohar@gmail.com> wrote:
> >
> > On Wednesday 11 July 2018 16:45:01 Pali Rohár wrote:
> > > On Wednesday 11 July 2018 16:27:07 Luiz Augusto von Dentz wrote:
> > > > One way to solve all of these is that we would expose the remote
> > > > endpoints using MediaEndpoint1
> > >
> > > So client application (like pulseadio) would see list of remote
> > > endpoints (one for each codec) and choose one for connection?
> > >
> > > Looks like this should solve this problem.
> >
> > Are there any progress on such API in bluez?
> >
> > On pulseaudio mailing list other people proposed patches for other A2DP
> > codecs and basically bluez API for choosing A2DP codec is still missing
> > part...
> 
> Im currenlty on vacation but will try to find time for that, that said
> that shouldn't stop us to include support for other codecs, the last
> set seems to have some sort of priority for ordering the registration
> of the codecs.
> 

Let us know when you have something to see/try!
I'm happy to do testing of the patches. 

People are currently eager to get support for multiple BT audio codecs working and merged upstream :)


Thanks,

-- Pasi

Re: bluez: dbus method call for switching endpoint

[Luiz Augusto von Dentz]

Hi Pasi,

On Fri, Dec 28, 2018 at 4:46 PM Pasi Kärkkäinen <pasik@iki.fi> wrote:
>
> Hi Luiz,
>
> On Tue, Dec 18, 2018 at 01:02:39PM -0300, Luiz Augusto von Dentz wrote:
> > Hi Pali,
> >
> > On Sat, Dec 15, 2018 at 5:29 PM Pali Rohár <pali.rohar@gmail.com> wrote:
> > >
> > > On Wednesday 11 July 2018 16:45:01 Pali Rohár wrote:
> > > > On Wednesday 11 July 2018 16:27:07 Luiz Augusto von Dentz wrote:
> > > > > One way to solve all of these is that we would expose the remote
> > > > > endpoints using MediaEndpoint1
> > > >
> > > > So client application (like pulseadio) would see list of remote
> > > > endpoints (one for each codec) and choose one for connection?
> > > >
> > > > Looks like this should solve this problem.
> > >
> > > Are there any progress on such API in bluez?
> > >
> > > On pulseaudio mailing list other people proposed patches for other A2DP
> > > codecs and basically bluez API for choosing A2DP codec is still missing
> > > part...
> >
> > Im currenlty on vacation but will try to find time for that, that said
> > that shouldn't stop us to include support for other codecs, the last
> > set seems to have some sort of priority for ordering the registration
> > of the codecs.
> >
>
> Let us know when you have something to see/try!
> I'm happy to do testing of the patches.
>
> People are currently eager to get support for multiple BT audio codecs working and merged upstream :)

Note that it is very unlikely that this API would allow multiple
codecs at the same time, headsets normally only allow one
configuration at time. Making it possible to switch codecs is more of
a workaround for headsets that don't honor the codec priority since
they normally codec back, although some model no longer configure a
stream just wait the source.

Regarding the API I still didn't have time to start it, so it will
take a little longer than I antecipated.
-- 
Luiz Augusto von Dentz

Re: bluez: dbus method call for switching endpoint

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 4032 bytes --]

On Friday 28 December 2018 19:10:11 Luiz Augusto von Dentz wrote:
> Hi Pasi,
> 
> On Fri, Dec 28, 2018 at 4:46 PM Pasi Kärkkäinen <pasik@iki.fi> wrote:
> >
> > Hi Luiz,
> >
> > On Tue, Dec 18, 2018 at 01:02:39PM -0300, Luiz Augusto von Dentz wrote:
> > > Hi Pali,
> > >
> > > On Sat, Dec 15, 2018 at 5:29 PM Pali Rohár <pali.rohar@gmail.com> wrote:
> > > >
> > > > On Wednesday 11 July 2018 16:45:01 Pali Rohár wrote:
> > > > > On Wednesday 11 July 2018 16:27:07 Luiz Augusto von Dentz wrote:
> > > > > > One way to solve all of these is that we would expose the remote
> > > > > > endpoints using MediaEndpoint1
> > > > >
> > > > > So client application (like pulseadio) would see list of remote
> > > > > endpoints (one for each codec) and choose one for connection?
> > > > >
> > > > > Looks like this should solve this problem.
> > > >
> > > > Are there any progress on such API in bluez?
> > > >
> > > > On pulseaudio mailing list other people proposed patches for other A2DP
> > > > codecs and basically bluez API for choosing A2DP codec is still missing
> > > > part...
> > >
> > > Im currenlty on vacation but will try to find time for that, that said
> > > that shouldn't stop us to include support for other codecs, the last
> > > set seems to have some sort of priority for ordering the registration
> > > of the codecs.
> > >
> >
> > Let us know when you have something to see/try!
> > I'm happy to do testing of the patches.
> >
> > People are currently eager to get support for multiple BT audio codecs working and merged upstream :)
> 
> Note that it is very unlikely that this API would allow multiple
> codecs at the same time, headsets normally only allow one
> configuration at time.

Multiple codecs at the same time is not needed.

> Making it possible to switch codecs is more of
> a workaround for headsets that don't honor the codec priority since
> they normally codec back, although some model no longer configure a
> stream just wait the source.

First thing is to provide list of supported codecs via dbus, so
pulseaudio would know which codecs remote device (headset) support. And
ideally tell it also to user.

Second thing which is needed, is ability to switch to different
supported codec. If headset supports 4 codecs, then user wants to switch
from first codec to second and compare which is "better for him".

And third thing, some headsets remember last used codec for particular
notebook and when headset initialize connection it uses this codec.
So if pulseaudio (or any other application) adds support for a new
codec, which is also supported by that headset, then this codec would
not be used -- even when it has higher priority in pulseaudio.

I think probably all headsets (or at least majority of them) initialize
connection to last "notebook/phone" device after starting it up.

So priority defined by pulseaudio is not going to be used in above cases
and we need a way in pulseaudio to switch from one codec to another.

And forth thing, people lot of times listen music and their music is
stored in some lossy compression codecs (MP3, AAC, ...). A2DP supports
of these codecs and pulseaudio has already support for pass-through
different codec payloads to sound card (if sound card driver support
is). So this would allow us to e.g. pass-through MP3 or AAC data to
supported headset without need to decode and encode again. Pulseaudio in
this case can take care for switching from "better A2DP codec" to AAC
when input application source is already in AAC; and then back to that
previous "better A2DP codec" after AAC playback file finish.

I think that similar technique is already used in Apple products which
propagates AAC format.

Therefore I do not think switching codec is some king of workaround or
hack, but fully valid use case.

> Regarding the API I still didn't have time to start it, so it will
> take a little longer than I antecipated.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: bluez: dbus method call for switching endpoint

[Luiz Augusto von Dentz]

Hi Pali, Pasi,

On Sat, Dec 29, 2018 at 10:08 AM Pali Rohár <pali.rohar@gmail.com> wrote:
>
> On Friday 28 December 2018 19:10:11 Luiz Augusto von Dentz wrote:
> > Hi Pasi,
> >
> > On Fri, Dec 28, 2018 at 4:46 PM Pasi Kärkkäinen <pasik@iki.fi> wrote:
> > >
> > > Hi Luiz,
> > >
> > > On Tue, Dec 18, 2018 at 01:02:39PM -0300, Luiz Augusto von Dentz wrote:
> > > > Hi Pali,
> > > >
> > > > On Sat, Dec 15, 2018 at 5:29 PM Pali Rohár <pali.rohar@gmail.com> wrote:
> > > > >
> > > > > On Wednesday 11 July 2018 16:45:01 Pali Rohár wrote:
> > > > > > On Wednesday 11 July 2018 16:27:07 Luiz Augusto von Dentz wrote:
> > > > > > > One way to solve all of these is that we would expose the remote
> > > > > > > endpoints using MediaEndpoint1
> > > > > >
> > > > > > So client application (like pulseadio) would see list of remote
> > > > > > endpoints (one for each codec) and choose one for connection?
> > > > > >
> > > > > > Looks like this should solve this problem.
> > > > >
> > > > > Are there any progress on such API in bluez?
> > > > >
> > > > > On pulseaudio mailing list other people proposed patches for other A2DP
> > > > > codecs and basically bluez API for choosing A2DP codec is still missing
> > > > > part...
> > > >
> > > > Im currenlty on vacation but will try to find time for that, that said
> > > > that shouldn't stop us to include support for other codecs, the last
> > > > set seems to have some sort of priority for ordering the registration
> > > > of the codecs.
> > > >
> > >
> > > Let us know when you have something to see/try!
> > > I'm happy to do testing of the patches.
> > >
> > > People are currently eager to get support for multiple BT audio codecs working and merged upstream :)
> >
> > Note that it is very unlikely that this API would allow multiple
> > codecs at the same time, headsets normally only allow one
> > configuration at time.
>
> Multiple codecs at the same time is not needed.
>
> > Making it possible to switch codecs is more of
> > a workaround for headsets that don't honor the codec priority since
> > they normally codec back, although some model no longer configure a
> > stream just wait the source.
>
> First thing is to provide list of supported codecs via dbus, so
> pulseaudio would know which codecs remote device (headset) support. And
> ideally tell it also to user.
>
> Second thing which is needed, is ability to switch to different
> supported codec. If headset supports 4 codecs, then user wants to switch
> from first codec to second and compare which is "better for him".
>
> And third thing, some headsets remember last used codec for particular
> notebook and when headset initialize connection it uses this codec.
> So if pulseaudio (or any other application) adds support for a new
> codec, which is also supported by that headset, then this codec would
> not be used -- even when it has higher priority in pulseaudio.
>
> I think probably all headsets (or at least majority of them) initialize
> connection to last "notebook/phone" device after starting it up.
>
> So priority defined by pulseaudio is not going to be used in above cases
> and we need a way in pulseaudio to switch from one codec to another.
>
> And forth thing, people lot of times listen music and their music is
> stored in some lossy compression codecs (MP3, AAC, ...). A2DP supports
> of these codecs and pulseaudio has already support for pass-through
> different codec payloads to sound card (if sound card driver support
> is). So this would allow us to e.g. pass-through MP3 or AAC data to
> supported headset without need to decode and encode again. Pulseaudio in
> this case can take care for switching from "better A2DP codec" to AAC
> when input application source is already in AAC; and then back to that
> previous "better A2DP codec" after AAC playback file finish.
>
> I think that similar technique is already used in Apple products which
> propagates AAC format.
>
> Therefore I do not think switching codec is some king of workaround or
> hack, but fully valid use case.

Except that we can't do that because we cannot garanteed there wont be
other sources active e.g. system notifications, etc, so in practice
complex/expensive codecs such as MP3 and AAC are hard to use since
that would mean we would have to encode on the fly. Perhaps there we
could have a setting for these type of codecs so the user would have
to opt-in if he want to just listen to those files, though if they are
using streaming services they normally decode on their own so AAC and
MP3 endpoint are not that useful with the likes of youtube, spotify,
etc.

> > Regarding the API I still didn't have time to start it, so it will
> > take a little longer than I antecipated.

Ive just sent the patches adding support to switch the endpoints, Ive
only tested with a couple of sony headsets so I would appreciate if
you guys could try it as well. Note that the SetConfiguration must
come from the same D-Bus connection as the endpoint that would be
used, also if there is already an stream in place it must also be from
the same client since it would be terminated in the process, this is
to prevent entities fighting to configure with its own priority though
usually we only PA endpoints, if you want to bypass this just for now
I have you can use the following changes:

diff --git a/profiles/audio/a2dp.c b/profiles/audio/a2dp.c
index cda2b6c64..e5e1e0d1c 100644
--- a/profiles/audio/a2dp.c
+++ b/profiles/audio/a2dp.c
@@ -1574,10 +1574,11 @@ static int a2dp_reconfig(struct a2dp_channel
*chan, const char *sender,

                /* Attempt to reconfigure if a stream already exists */
                if (tmp->stream) {
-                       /* Only allow switching sep from the same sender */
-                       if (strcmp(sender, lsep->endpoint->get_name(tmp,
+                       /* Only allow switching sep from the same sender
+                       if (strcmp(sender, tmp->endpoint->get_name(tmp,
                                                        tmp->user_data)))
                                return -EPERM;
+                       */

                        err = avdtp_close(chan->session, tmp->stream, FALSE);
                        if (err < 0) {
@@ -1627,12 +1628,31 @@ static DBusMessage
*set_configuration(DBusConnection *conn, DBusMessage *msg,
        dbus_message_iter_get_basic(&args, &path);
        dbus_message_iter_next(&args);

-       lsep = find_sep(chan->server, avdtp_get_type(rsep->sep), sender, path);
+       service = avdtp_get_codec(rsep->sep);
+       codec = (struct avdtp_media_codec_capability *) service->data;
+
+       if (!strcmp(path, "/")) {
+               GSList *l;
+
+               l = avdtp_get_type(rsep->sep) == AVDTP_SEP_TYPE_SINK ?
+                                       chan->server->sources :
+                                       chan->server->sinks;
+
+               for (; l; l = g_slist_next(l)) {
+                       if (endpoint_match_codec_ind(chan->session, codec,
+                                                               l->data))
+                               break;
+               }
+
+               if (l)
+                       lsep = l->data;
+       } else
+               lsep = find_sep(chan->server, avdtp_get_type(rsep->sep), sender,
+                               path);
+
        if (!lsep)
                return btd_error_invalid_args(msg);

-       service = avdtp_get_codec(rsep->sep);
-       codec = (struct avdtp_media_codec_capability *) service->data;

        /* Check if codec really matches */
        if (!endpoint_match_codec_ind(chan->session, codec, lsep))


-- 
Luiz Augusto von Dentz

Re: bluez: dbus method call for switching endpoint

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 2141 bytes --]

On Tuesday 08 January 2019 13:44:24 Luiz Augusto von Dentz wrote:
> On Sat, Dec 29, 2018 at 10:08 AM Pali Rohár <pali.rohar@gmail.com> wrote:
> > And forth thing, people lot of times listen music and their music is
> > stored in some lossy compression codecs (MP3, AAC, ...). A2DP supports
> > of these codecs and pulseaudio has already support for pass-through
> > different codec payloads to sound card (if sound card driver support
> > is). So this would allow us to e.g. pass-through MP3 or AAC data to
> > supported headset without need to decode and encode again. Pulseaudio in
> > this case can take care for switching from "better A2DP codec" to AAC
> > when input application source is already in AAC; and then back to that
> > previous "better A2DP codec" after AAC playback file finish.
> >
> > I think that similar technique is already used in Apple products which
> > propagates AAC format.
> >
> > Therefore I do not think switching codec is some king of workaround or
> > hack, but fully valid use case.
> 
> Except that we can't do that because we cannot garanteed there wont be
> other sources active e.g. system notifications, etc, so in practice
> complex/expensive codecs such as MP3 and AAC are hard to use since
> that would mean we would have to encode on the fly. Perhaps there we
> could have a setting for these type of codecs so the user would have
> to opt-in if he want to just listen to those files, though if they are
> using streaming services they normally decode on their own so AAC and
> MP3 endpoint are not that useful with the likes of youtube, spotify,
> etc.

IIRC pulseaudio has already API for pass-through of MP3 and AAC and at
one time can only one application send stream, so there are no system
notifications.

You can also see checkboxes for codecs which can be enabled for
pass-through for digital sound cards (e.g. HDMI output) in pavucontrol.

So I do not think that this is a problem. Bluetooth "A2DP card" in
pulseaudio can behave in exactly same way like existing HDMI AAC output,
which is already working.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: bluez: dbus method call for switching endpoint

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 1115 bytes --]

On Tuesday 08 January 2019 13:44:24 Luiz Augusto von Dentz wrote:
> > > Regarding the API I still didn't have time to start it, so it will
> > > take a little longer than I antecipated.
> 
> Ive just sent the patches adding support to switch the endpoints, Ive
> only tested with a couple of sony headsets so I would appreciate if
> you guys could try it as well. Note that the SetConfiguration must
> come from the same D-Bus connection as the endpoint that would be
> used, also if there is already an stream in place it must also be from
> the same client since it would be terminated in the process, this is
> to prevent entities fighting to configure with its own priority though
> usually we only PA endpoints, if you want to bypass this just for now

Great! Once patches would be ready I would look at my last A2DP
pulseaudio patches [1] and would try to implement switching, including
support for bi-directional FastStream codec -- which can benefit from
it.

[1] - https://lists.freedesktop.org/archives/pulseaudio-discuss/2018-July/030344.html

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: bluez: dbus method call for switching endpoint

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 1614 bytes --]

On Tuesday 08 January 2019 17:56:12 Pali Rohár wrote:
> On Tuesday 08 January 2019 13:44:24 Luiz Augusto von Dentz wrote:
> > > > Regarding the API I still didn't have time to start it, so it will
> > > > take a little longer than I antecipated.
> > 
> > Ive just sent the patches adding support to switch the endpoints, Ive
> > only tested with a couple of sony headsets so I would appreciate if
> > you guys could try it as well. Note that the SetConfiguration must
> > come from the same D-Bus connection as the endpoint that would be
> > used, also if there is already an stream in place it must also be from
> > the same client since it would be terminated in the process, this is
> > to prevent entities fighting to configure with its own priority though
> > usually we only PA endpoints, if you want to bypass this just for now
> 
> Great! Once patches would be ready I would look at my last A2DP
> pulseaudio patches [1] and would try to implement switching, including
> support for bi-directional FastStream codec -- which can benefit from
> it.
> 
> [1] - https://lists.freedesktop.org/archives/pulseaudio-discuss/2018-July/030344.html

Hi! I applied your 6 patches from https://marc.info/?l=linux-bluetooth&r=1&b=201901&w=2
but whatever I did I was not able to locate in dbus hierarchy list of
A2DP codecs supported by device.

I thought that somewhere in

qdbus --system org.bluez /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX

I found A2DP codec capabilities...

So how to get list of all supported A2DP codecs for particular device?

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: bluez: dbus method call for switching endpoint

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 2195 bytes --]

On Wednesday 09 January 2019 19:03:40 Pali Rohár wrote:
> On Tuesday 08 January 2019 17:56:12 Pali Rohár wrote:
> > On Tuesday 08 January 2019 13:44:24 Luiz Augusto von Dentz wrote:
> > > > > Regarding the API I still didn't have time to start it, so it will
> > > > > take a little longer than I antecipated.
> > > 
> > > Ive just sent the patches adding support to switch the endpoints, Ive
> > > only tested with a couple of sony headsets so I would appreciate if
> > > you guys could try it as well. Note that the SetConfiguration must
> > > come from the same D-Bus connection as the endpoint that would be
> > > used, also if there is already an stream in place it must also be from
> > > the same client since it would be terminated in the process, this is
> > > to prevent entities fighting to configure with its own priority though
> > > usually we only PA endpoints, if you want to bypass this just for now
> > 
> > Great! Once patches would be ready I would look at my last A2DP
> > pulseaudio patches [1] and would try to implement switching, including
> > support for bi-directional FastStream codec -- which can benefit from
> > it.
> > 
> > [1] - https://lists.freedesktop.org/archives/pulseaudio-discuss/2018-July/030344.html
> 
> Hi! I applied your 6 patches from https://marc.info/?l=linux-bluetooth&r=1&b=201901&w=2
> but whatever I did I was not able to locate in dbus hierarchy list of
> A2DP codecs supported by device.
> 
> I thought that somewhere in
> 
> qdbus --system org.bluez /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX
> 
> I found A2DP codec capabilities...
> 
> So how to get list of all supported A2DP codecs for particular device?

Ah, I forgot to start bluetoothd with --experimental option. After that
I see sep*

/
/org
/org/bluez
/org/bluez/hci0
/org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX
/org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX/sep1
/org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX/sep3
/org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX/sep5

and qdbus --system org.bluez /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX/sep1 org.freedesktop.DBus.Properties.GetAll org.bluez.MediaEndpoint1
list them correctly.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: bluez: dbus method call for switching endpoint

[Luiz Augusto von Dentz]

Hi Pali,

On Wed, Jan 9, 2019 at 3:14 PM Pali Rohár <pali.rohar@gmail.com> wrote:
>
> On Wednesday 09 January 2019 19:03:40 Pali Rohár wrote:
> > On Tuesday 08 January 2019 17:56:12 Pali Rohár wrote:
> > > On Tuesday 08 January 2019 13:44:24 Luiz Augusto von Dentz wrote:
> > > > > > Regarding the API I still didn't have time to start it, so it will
> > > > > > take a little longer than I antecipated.
> > > >
> > > > Ive just sent the patches adding support to switch the endpoints, Ive
> > > > only tested with a couple of sony headsets so I would appreciate if
> > > > you guys could try it as well. Note that the SetConfiguration must
> > > > come from the same D-Bus connection as the endpoint that would be
> > > > used, also if there is already an stream in place it must also be from
> > > > the same client since it would be terminated in the process, this is
> > > > to prevent entities fighting to configure with its own priority though
> > > > usually we only PA endpoints, if you want to bypass this just for now
> > >
> > > Great! Once patches would be ready I would look at my last A2DP
> > > pulseaudio patches [1] and would try to implement switching, including
> > > support for bi-directional FastStream codec -- which can benefit from
> > > it.
> > >
> > > [1] - https://lists.freedesktop.org/archives/pulseaudio-discuss/2018-July/030344.html
> >
> > Hi! I applied your 6 patches from https://marc.info/?l=linux-bluetooth&r=1&b=201901&w=2
> > but whatever I did I was not able to locate in dbus hierarchy list of
> > A2DP codecs supported by device.
> >
> > I thought that somewhere in
> >
> > qdbus --system org.bluez /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX
> >
> > I found A2DP codec capabilities...
> >
> > So how to get list of all supported A2DP codecs for particular device?
>
> Ah, I forgot to start bluetoothd with --experimental option. After that
> I see sep*
>
> /
> /org
> /org/bluez
> /org/bluez/hci0
> /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX
> /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX/sep1
> /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX/sep3
> /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX/sep5
>
> and qdbus --system org.bluez /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX/sep1 org.freedesktop.DBus.Properties.GetAll org.bluez.MediaEndpoint1
> list them correctly.

You can use d-feet as well, btw did you forget to paste sep2 and sep4
or the device just skip them? Ive made sure not to filter any
endpoints even if they would not have any matching local endpoints so
we allow new endpoints to be registered later, anyway SetConfiguration
actually checks that endpoints matches.

-- 
Luiz Augusto von Dentz

Re: bluez: dbus method call for switching endpoint

[Pali Rohár]

On Thursday 10 January 2019 08:29:02 Luiz Augusto von Dentz wrote:
> Hi Pali,
> 
> On Wed, Jan 9, 2019 at 3:14 PM Pali Rohár <pali.rohar@gmail.com> wrote:
> >
> > On Wednesday 09 January 2019 19:03:40 Pali Rohár wrote:
> > > On Tuesday 08 January 2019 17:56:12 Pali Rohár wrote:
> > > > On Tuesday 08 January 2019 13:44:24 Luiz Augusto von Dentz wrote:
> > > > > > > Regarding the API I still didn't have time to start it, so it will
> > > > > > > take a little longer than I antecipated.
> > > > >
> > > > > Ive just sent the patches adding support to switch the endpoints, Ive
> > > > > only tested with a couple of sony headsets so I would appreciate if
> > > > > you guys could try it as well. Note that the SetConfiguration must
> > > > > come from the same D-Bus connection as the endpoint that would be
> > > > > used, also if there is already an stream in place it must also be from
> > > > > the same client since it would be terminated in the process, this is
> > > > > to prevent entities fighting to configure with its own priority though
> > > > > usually we only PA endpoints, if you want to bypass this just for now
> > > >
> > > > Great! Once patches would be ready I would look at my last A2DP
> > > > pulseaudio patches [1] and would try to implement switching, including
> > > > support for bi-directional FastStream codec -- which can benefit from
> > > > it.
> > > >
> > > > [1] - https://lists.freedesktop.org/archives/pulseaudio-discuss/2018-July/030344.html
> > >
> > > Hi! I applied your 6 patches from https://marc.info/?l=linux-bluetooth&r=1&b=201901&w=2
> > > but whatever I did I was not able to locate in dbus hierarchy list of
> > > A2DP codecs supported by device.
> > >
> > > I thought that somewhere in
> > >
> > > qdbus --system org.bluez /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX
> > >
> > > I found A2DP codec capabilities...
> > >
> > > So how to get list of all supported A2DP codecs for particular device?
> >
> > Ah, I forgot to start bluetoothd with --experimental option. After that
> > I see sep*
> >
> > /
> > /org
> > /org/bluez
> > /org/bluez/hci0
> > /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX
> > /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX/sep1
> > /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX/sep3
> > /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX/sep5
> >
> > and qdbus --system org.bluez /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX/sep1 org.freedesktop.DBus.Properties.GetAll org.bluez.MediaEndpoint1
> > list them correctly.
> 
> You can use d-feet as well, btw did you forget to paste sep2 and sep4
> or the device just skip them?

No. This headset exports only sep1, sep3 and sep5. And supports SBC,
aptX and FastStream codecs. So count is correct, just numbering is not
canonical.

> Ive made sure not to filter any
> endpoints even if they would not have any matching local endpoints so
> we allow new endpoints to be registered later, anyway SetConfiguration
> actually checks that endpoints matches.
> 

-- 
Pali Rohár
pali.rohar@gmail.com

Re: bluez: dbus method call for switching endpoint

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 813 bytes --]

On Tuesday 08 January 2019 13:44:24 Luiz Augusto von Dentz wrote:
> On Sat, Dec 29, 2018 at 10:08 AM Pali Rohár <pali.rohar@gmail.com> wrote:
> > On Friday 28 December 2018 19:10:11 Luiz Augusto von Dentz wrote:
> > > Regarding the API I still didn't have time to start it, so it will
> > > take a little longer than I antecipated.
> 
> Ive just sent the patches adding support to switch the endpoints, Ive
> only tested with a couple of sony headsets so I would appreciate if
> you guys could try it as well.

Now I implemented profile switching into pulseaudio. Seems that bluez
DBus API is working fine with tested headsets. Patches for pulseaudio
are on pulseaudio mailing list.

What else is needed for including these patches into bluez officially?

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: bluez: dbus method call for switching endpoint

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 4335 bytes --]

On Thursday 10 January 2019 12:59:10 Pali Rohár wrote:
> On Thursday 10 January 2019 08:29:02 Luiz Augusto von Dentz wrote:
> > Hi Pali,
> > 
> > On Wed, Jan 9, 2019 at 3:14 PM Pali Rohár <pali.rohar@gmail.com> wrote:
> > >
> > > On Wednesday 09 January 2019 19:03:40 Pali Rohár wrote:
> > > > On Tuesday 08 January 2019 17:56:12 Pali Rohár wrote:
> > > > > On Tuesday 08 January 2019 13:44:24 Luiz Augusto von Dentz wrote:
> > > > > > > > Regarding the API I still didn't have time to start it, so it will
> > > > > > > > take a little longer than I antecipated.
> > > > > >
> > > > > > Ive just sent the patches adding support to switch the endpoints, Ive
> > > > > > only tested with a couple of sony headsets so I would appreciate if
> > > > > > you guys could try it as well. Note that the SetConfiguration must
> > > > > > come from the same D-Bus connection as the endpoint that would be
> > > > > > used, also if there is already an stream in place it must also be from
> > > > > > the same client since it would be terminated in the process, this is
> > > > > > to prevent entities fighting to configure with its own priority though
> > > > > > usually we only PA endpoints, if you want to bypass this just for now
> > > > >
> > > > > Great! Once patches would be ready I would look at my last A2DP
> > > > > pulseaudio patches [1] and would try to implement switching, including
> > > > > support for bi-directional FastStream codec -- which can benefit from
> > > > > it.
> > > > >
> > > > > [1] - https://lists.freedesktop.org/archives/pulseaudio-discuss/2018-July/030344.html
> > > >
> > > > Hi! I applied your 6 patches from https://marc.info/?l=linux-bluetooth&r=1&b=201901&w=2
> > > > but whatever I did I was not able to locate in dbus hierarchy list of
> > > > A2DP codecs supported by device.
> > > >
> > > > I thought that somewhere in
> > > >
> > > > qdbus --system org.bluez /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX
> > > >
> > > > I found A2DP codec capabilities...
> > > >
> > > > So how to get list of all supported A2DP codecs for particular device?
> > >
> > > Ah, I forgot to start bluetoothd with --experimental option. After that
> > > I see sep*
> > >
> > > /
> > > /org
> > > /org/bluez
> > > /org/bluez/hci0
> > > /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX
> > > /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX/sep1
> > > /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX/sep3
> > > /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX/sep5
> > >
> > > and qdbus --system org.bluez /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX/sep1 org.freedesktop.DBus.Properties.GetAll org.bluez.MediaEndpoint1
> > > list them correctly.
> > 
> > You can use d-feet as well, btw did you forget to paste sep2 and sep4
> > or the device just skip them?
> 
> No. This headset exports only sep1, sep3 and sep5. And supports SBC,
> aptX and FastStream codecs. So count is correct, just numbering is not
> canonical.

Still, I have a question. Why there is only sep1, sep3 and sep5? Where
are numbers 2 and 4? Why numbering is not canonical: 1, 2, 3?

If it could help, here is output from avinfo:

Connecting ... 
Stream End-Point #1: Audio Sink 
	Media Codec: SBC
		Channel Modes: Mono DualChannel Stereo JointStereo
		Frequencies: 16Khz 32Khz 44.1Khz 48Khz 
		Subbands: 4 8
		Blocks: 4 8 12 16 
		Bitpool Range: 2-53
	Content Protection: SCMS-T
Stream End-Point #5: Audio Sink 
	Media Codec: Vendor Specific A2DP Codec
		Vendor ID 0x0000004f
		Vendor Specific Codec ID 0x0001
		Vendor Specific Data: 0xf2
		Vendor Specific Value (aptX)
			Frequencies: 16kHz 32kHz 44.1kHz 48kHz 
			Channel modes: Stereo 
Stream End-Point #3: Audio Sink 
	Media Codec: Vendor Specific A2DP Codec
		Vendor ID 0x0000000a
		Vendor Specific Codec ID 0x0001
		Vendor Specific Data: 0x03 0x23
		Vendor Specific Value (FastStream)
			Directions: sink source 
			Sink Frequencies: 44.1kHz 48kHz 
			Source Frequencies: 16kHz 

You can see that there is endpoint 1, 5 and 3.

Who choose numbers for endpoints?

> > Ive made sure not to filter any
> > endpoints even if they would not have any matching local endpoints so
> > we allow new endpoints to be registered later, anyway SetConfiguration
> > actually checks that endpoints matches.
> > 
> 

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]