Re: bluez: dbus method call for switching endpoint

["Pali Rohár" <pali.rohar@gmail.com>]

[-- 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 --]