bluez: A2DP backchannel

bluez: A2DP backchannel

[Pali Rohár]

Hi!

Some vendor A2DP bluetooth codecs like FastStream or aptX Low Latency
supports backchannel. Which means that they are bi-directional and in
A2DP they supports not only (music) playback, but also receiving
backchannel (microphone) voice.

How to establish this bi-directional A2DP transfer with backchannel via
bluez daemon?

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

Re: bluez: A2DP backchannel

[Luiz Augusto von Dentz]

Hi Pali,

On Wed, Jul 11, 2018 at 2:04 PM, Pali Roh=C3=A1r <pali.rohar@gmail.com> wro=
te:
> Hi!
>
> Some vendor A2DP bluetooth codecs like FastStream or aptX Low Latency
> supports backchannel. Which means that they are bi-directional and in
> A2DP they supports not only (music) playback, but also receiving
> backchannel (microphone) voice.
>
> How to establish this bi-directional A2DP transfer with backchannel via
> bluez daemon?

There is no such thing as bi-directional in AVDTP, which is a screw up
from the spec authors, luckily we don't have to stick to it since our
sockets are bi-directional so you can send and receive data at same
time, though the configuration must be the same in either direction
otherwise we would have to support transport multiplexing to have
multiple configuration done using the same channel.

--=20
Luiz Augusto von Dentz

Re: bluez: A2DP backchannel

[Pali Rohár]

On Wednesday 11 July 2018 16:34:14 Luiz Augusto von Dentz wrote:
> Hi Pali,
> 
> On Wed, Jul 11, 2018 at 2:04 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > Hi!
> >
> > Some vendor A2DP bluetooth codecs like FastStream or aptX Low Latency
> > supports backchannel. Which means that they are bi-directional and in
> > A2DP they supports not only (music) playback, but also receiving
> > backchannel (microphone) voice.
> >
> > How to establish this bi-directional A2DP transfer with backchannel via
> > bluez daemon?
> 
> There is no such thing as bi-directional in AVDTP, which is a screw up
> from the spec authors,

So it means that those vendor A2DP codecs somehow extends AVDTP, right?
I would need to figure out how A2DP devices send voice data... At least
backchannel activation for FastStream is via one bit in codec parameters
like other codec parameters.

> luckily we don't have to stick to it since our
> sockets are bi-directional so you can send and receive data at same
> time, though the configuration must be the same in either direction
> otherwise we would have to support transport multiplexing to have
> multiple configuration done using the same channel.

So does it mean that I can read from file descriptor received from dbus
which is used for sending encoded A2DP audio samples? And if other side
(e.g device with FastStream or aptX LL vendor codec) send voice via A2DP
then I receive them on that file descriptor?

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

Re: bluez: A2DP backchannel

[Pali Rohár]

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

On Wednesday 11 July 2018 16:37:47 Pali Rohár wrote:
> On Wednesday 11 July 2018 16:34:14 Luiz Augusto von Dentz wrote:
> > Hi Pali,
> > 
> > On Wed, Jul 11, 2018 at 2:04 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > > Hi!
> > >
> > > Some vendor A2DP bluetooth codecs like FastStream or aptX Low Latency
> > > supports backchannel. Which means that they are bi-directional and in
> > > A2DP they supports not only (music) playback, but also receiving
> > > backchannel (microphone) voice.
> > >
> > > How to establish this bi-directional A2DP transfer with backchannel via
> > > bluez daemon?
> > 
> > There is no such thing as bi-directional in AVDTP, which is a screw up
> > from the spec authors,
> 
> So it means that those vendor A2DP codecs somehow extends AVDTP, right?
> I would need to figure out how A2DP devices send voice data... At least
> backchannel activation for FastStream is via one bit in codec parameters
> like other codec parameters.
> 
> > luckily we don't have to stick to it since our
> > sockets are bi-directional so you can send and receive data at same
> > time, though the configuration must be the same in either direction
> > otherwise we would have to support transport multiplexing to have
> > multiple configuration done using the same channel.
> 
> So does it mean that I can read from file descriptor received from dbus
> which is used for sending encoded A2DP audio samples? And if other side
> (e.g device with FastStream or aptX LL vendor codec) send voice via A2DP
> then I receive them on that file descriptor?

Now I established A2DP connection with FastStream codec and in btmon I
see that my headset started sending some data to channel 65 in this A2DP
mode.

So definitely it is possible to send data from headset to computer (that
backchannel) in A2DP mode despite what A2DP specification says.

I managed to modify pulseaudio code to start encoding and streaming
FastStream data to headset and it is working.

Now the challenge would be how to get those data which headset send to
channel 65? Is bluez really sending them via file descriptor which is
used for writing from host to headset?

Via btmon I was able to dump data from this channel 65 and via some
sed/perl magic I converted received voice data and played it:

$ btmon > /tmp/dump
CTRL+C
$ grep 'Channel: 65' -A 14 /tmp/dump | grep '^        ' | sed 's/^        //;s/  .*//' | tr ' ' '\n' | perl -ne 'print chr(hex($_))' > /tmp/voice.sbc
$ sbcdec -f /tmp/voice.snd /tmp/voice.sbc
$ play /tmp/voice.snd

And I heard clear voice. So FastStream is really just rebranded SBC
codec (with fixed parameters; without RTP) and in A2DP bluetooth profile
provides nice bi-directional channels.

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

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

Re: bluez: A2DP backchannel

[Marcel Holtmann]

Hi Pali,

>>>> Some vendor A2DP bluetooth codecs like FastStream or aptX Low Latency
>>>> supports backchannel. Which means that they are bi-directional and in
>>>> A2DP they supports not only (music) playback, but also receiving
>>>> backchannel (microphone) voice.
>>>> 
>>>> How to establish this bi-directional A2DP transfer with backchannel via
>>>> bluez daemon?
>>> 
>>> There is no such thing as bi-directional in AVDTP, which is a screw up
>>> from the spec authors,
>> 
>> So it means that those vendor A2DP codecs somehow extends AVDTP, right?
>> I would need to figure out how A2DP devices send voice data... At least
>> backchannel activation for FastStream is via one bit in codec parameters
>> like other codec parameters.
>> 
>>> luckily we don't have to stick to it since our
>>> sockets are bi-directional so you can send and receive data at same
>>> time, though the configuration must be the same in either direction
>>> otherwise we would have to support transport multiplexing to have
>>> multiple configuration done using the same channel.
>> 
>> So does it mean that I can read from file descriptor received from dbus
>> which is used for sending encoded A2DP audio samples? And if other side
>> (e.g device with FastStream or aptX LL vendor codec) send voice via A2DP
>> then I receive them on that file descriptor?
> 
> Now I established A2DP connection with FastStream codec and in btmon I
> see that my headset started sending some data to channel 65 in this A2DP
> mode.
> 
> So definitely it is possible to send data from headset to computer (that
> backchannel) in A2DP mode despite what A2DP specification says.
> 
> I managed to modify pulseaudio code to start encoding and streaming
> FastStream data to headset and it is working.
> 
> Now the challenge would be how to get those data which headset send to
> channel 65? Is bluez really sending them via file descriptor which is
> used for writing from host to headset?
> 
> Via btmon I was able to dump data from this channel 65 and via some
> sed/perl magic I converted received voice data and played it:
> 
> $ btmon > /tmp/dump
> CTRL+C
> $ grep 'Channel: 65' -A 14 /tmp/dump | grep '^        ' | sed 's/^        //;s/  .*//' | tr ' ' '\n' | perl -ne 'print chr(hex($_))' > /tmp/voice.sbc
> $ sbcdec -f /tmp/voice.snd /tmp/voice.sbc
> $ play /tmp/voice.snd
> 
> And I heard clear voice. So FastStream is really just rebranded SBC
> codec (with fixed parameters; without RTP) and in A2DP bluetooth profile
> provides nice bi-directional channels.

can you show us at least a few of these channel 65 frames from btmon decoding. If it is via L2CAP fixed PSM, then in theory there needs to be some sort of channel establishment. Or if this via L2CAP fixed CID, then it is essentially unicast connectionless data. Both can be handled via L2CAP sockets, but you need to create sockets for these to receive the data.

On a side note, fixed CID 65 and fixed PSM 65 are both Bluetooth SIG reserved values, so seems like this codec is still violating the standard.

Regards

Marcel

Re: bluez: A2DP backchannel

[Pali Rohár]

[-- Attachment #1.1: Type: text/plain, Size: 3618 bytes --]

On Monday 30 July 2018 13:05:33 Marcel Holtmann wrote:
> Hi Pali,
> 
> >>>> Some vendor A2DP bluetooth codecs like FastStream or aptX Low Latency
> >>>> supports backchannel. Which means that they are bi-directional and in
> >>>> A2DP they supports not only (music) playback, but also receiving
> >>>> backchannel (microphone) voice.
> >>>> 
> >>>> How to establish this bi-directional A2DP transfer with backchannel via
> >>>> bluez daemon?
> >>> 
> >>> There is no such thing as bi-directional in AVDTP, which is a screw up
> >>> from the spec authors,
> >> 
> >> So it means that those vendor A2DP codecs somehow extends AVDTP, right?
> >> I would need to figure out how A2DP devices send voice data... At least
> >> backchannel activation for FastStream is via one bit in codec parameters
> >> like other codec parameters.
> >> 
> >>> luckily we don't have to stick to it since our
> >>> sockets are bi-directional so you can send and receive data at same
> >>> time, though the configuration must be the same in either direction
> >>> otherwise we would have to support transport multiplexing to have
> >>> multiple configuration done using the same channel.
> >> 
> >> So does it mean that I can read from file descriptor received from dbus
> >> which is used for sending encoded A2DP audio samples? And if other side
> >> (e.g device with FastStream or aptX LL vendor codec) send voice via A2DP
> >> then I receive them on that file descriptor?
> > 
> > Now I established A2DP connection with FastStream codec and in btmon I
> > see that my headset started sending some data to channel 65 in this A2DP
> > mode.
> > 
> > So definitely it is possible to send data from headset to computer (that
> > backchannel) in A2DP mode despite what A2DP specification says.
> > 
> > I managed to modify pulseaudio code to start encoding and streaming
> > FastStream data to headset and it is working.
> > 
> > Now the challenge would be how to get those data which headset send to
> > channel 65? Is bluez really sending them via file descriptor which is
> > used for writing from host to headset?
> > 
> > Via btmon I was able to dump data from this channel 65 and via some
> > sed/perl magic I converted received voice data and played it:
> > 
> > $ btmon > /tmp/dump
> > CTRL+C
> > $ grep 'Channel: 65' -A 14 /tmp/dump | grep '^        ' | sed 's/^        //;s/  .*//' | tr ' ' '\n' | perl -ne 'print chr(hex($_))' > /tmp/voice.sbc
> > $ sbcdec -f /tmp/voice.snd /tmp/voice.sbc
> > $ play /tmp/voice.snd
> > 
> > And I heard clear voice. So FastStream is really just rebranded SBC
> > codec (with fixed parameters; without RTP) and in A2DP bluetooth profile
> > provides nice bi-directional channels.
> 
> can you show us at least a few of these channel 65 frames from btmon decoding. If it is via L2CAP fixed PSM, then in theory there needs to be some sort of channel establishment. Or if this via L2CAP fixed CID, then it is essentially unicast connectionless data. Both can be handled via L2CAP sockets, but you need to create sockets for these to receive the data.
> 
> On a side note, fixed CID 65 and fixed PSM 65 are both Bluetooth SIG reserved values, so seems like this codec is still violating the standard.

Hi! In attachment is btmon dump with codec negotiation, connect, both
sink and source data and disconnect. Interesting is that now channel 65
is used for both sink and source. Yesterday when I was doing tests I
remember that different channel was used for microphone input and audio
playback.

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

[-- Attachment #1.2: btmon.gz --]
[-- Type: application/gzip, Size: 118765 bytes --]

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

Re: bluez: A2DP backchannel

[Marcel Holtmann]

Hi Pali,

>>>>>> Some vendor A2DP bluetooth codecs like FastStream or aptX Low Latency
>>>>>> supports backchannel. Which means that they are bi-directional and in
>>>>>> A2DP they supports not only (music) playback, but also receiving
>>>>>> backchannel (microphone) voice.
>>>>>> 
>>>>>> How to establish this bi-directional A2DP transfer with backchannel via
>>>>>> bluez daemon?
>>>>> 
>>>>> There is no such thing as bi-directional in AVDTP, which is a screw up
>>>>> from the spec authors,
>>>> 
>>>> So it means that those vendor A2DP codecs somehow extends AVDTP, right?
>>>> I would need to figure out how A2DP devices send voice data... At least
>>>> backchannel activation for FastStream is via one bit in codec parameters
>>>> like other codec parameters.
>>>> 
>>>>> luckily we don't have to stick to it since our
>>>>> sockets are bi-directional so you can send and receive data at same
>>>>> time, though the configuration must be the same in either direction
>>>>> otherwise we would have to support transport multiplexing to have
>>>>> multiple configuration done using the same channel.
>>>> 
>>>> So does it mean that I can read from file descriptor received from dbus
>>>> which is used for sending encoded A2DP audio samples? And if other side
>>>> (e.g device with FastStream or aptX LL vendor codec) send voice via A2DP
>>>> then I receive them on that file descriptor?
>>> 
>>> Now I established A2DP connection with FastStream codec and in btmon I
>>> see that my headset started sending some data to channel 65 in this A2DP
>>> mode.
>>> 
>>> So definitely it is possible to send data from headset to computer (that
>>> backchannel) in A2DP mode despite what A2DP specification says.
>>> 
>>> I managed to modify pulseaudio code to start encoding and streaming
>>> FastStream data to headset and it is working.
>>> 
>>> Now the challenge would be how to get those data which headset send to
>>> channel 65? Is bluez really sending them via file descriptor which is
>>> used for writing from host to headset?
>>> 
>>> Via btmon I was able to dump data from this channel 65 and via some
>>> sed/perl magic I converted received voice data and played it:
>>> 
>>> $ btmon > /tmp/dump
>>> CTRL+C
>>> $ grep 'Channel: 65' -A 14 /tmp/dump | grep '^        ' | sed 's/^        //;s/  .*//' | tr ' ' '\n' | perl -ne 'print chr(hex($_))' > /tmp/voice.sbc
>>> $ sbcdec -f /tmp/voice.snd /tmp/voice.sbc
>>> $ play /tmp/voice.snd
>>> 
>>> And I heard clear voice. So FastStream is really just rebranded SBC
>>> codec (with fixed parameters; without RTP) and in A2DP bluetooth profile
>>> provides nice bi-directional channels.
>> 
>> can you show us at least a few of these channel 65 frames from btmon decoding. If it is via L2CAP fixed PSM, then in theory there needs to be some sort of channel establishment. Or if this via L2CAP fixed CID, then it is essentially unicast connectionless data. Both can be handled via L2CAP sockets, but you need to create sockets for these to receive the data.
>> 
>> On a side note, fixed CID 65 and fixed PSM 65 are both Bluetooth SIG reserved values, so seems like this codec is still violating the standard.
> 
> Hi! In attachment is btmon dump with codec negotiation, connect, both
> sink and source data and disconnect. Interesting is that now channel 65
> is used for both sink and source. Yesterday when I was doing tests I
> remember that different channel was used for microphone input and audio
> playback.

so the Channel: 65 is a CID and is assigned dynamically. They can be different in each direction and by chance you get Source CID: 65 and Destination CID: 65. What I am seeing is that you get TX and RX on that PSM 25 which seems to be the established media channel. This means the file descriptor you already have for sending audio, just read from it and you should be getting the back channel receiving audio. L2CAP channels are always bi-directional.

Regards

Marcel

Re: bluez: A2DP backchannel

[Pali Rohár]

[-- Attachment #1.1: Type: text/plain, Size: 4591 bytes --]

On Monday 30 July 2018 20:15:37 Marcel Holtmann wrote:
> Hi Pali,
> 
> >>>>>> Some vendor A2DP bluetooth codecs like FastStream or aptX Low Latency
> >>>>>> supports backchannel. Which means that they are bi-directional and in
> >>>>>> A2DP they supports not only (music) playback, but also receiving
> >>>>>> backchannel (microphone) voice.
> >>>>>> 
> >>>>>> How to establish this bi-directional A2DP transfer with backchannel via
> >>>>>> bluez daemon?
> >>>>> 
> >>>>> There is no such thing as bi-directional in AVDTP, which is a screw up
> >>>>> from the spec authors,
> >>>> 
> >>>> So it means that those vendor A2DP codecs somehow extends AVDTP, right?
> >>>> I would need to figure out how A2DP devices send voice data... At least
> >>>> backchannel activation for FastStream is via one bit in codec parameters
> >>>> like other codec parameters.
> >>>> 
> >>>>> luckily we don't have to stick to it since our
> >>>>> sockets are bi-directional so you can send and receive data at same
> >>>>> time, though the configuration must be the same in either direction
> >>>>> otherwise we would have to support transport multiplexing to have
> >>>>> multiple configuration done using the same channel.
> >>>> 
> >>>> So does it mean that I can read from file descriptor received from dbus
> >>>> which is used for sending encoded A2DP audio samples? And if other side
> >>>> (e.g device with FastStream or aptX LL vendor codec) send voice via A2DP
> >>>> then I receive them on that file descriptor?
> >>> 
> >>> Now I established A2DP connection with FastStream codec and in btmon I
> >>> see that my headset started sending some data to channel 65 in this A2DP
> >>> mode.
> >>> 
> >>> So definitely it is possible to send data from headset to computer (that
> >>> backchannel) in A2DP mode despite what A2DP specification says.
> >>> 
> >>> I managed to modify pulseaudio code to start encoding and streaming
> >>> FastStream data to headset and it is working.
> >>> 
> >>> Now the challenge would be how to get those data which headset send to
> >>> channel 65? Is bluez really sending them via file descriptor which is
> >>> used for writing from host to headset?
> >>> 
> >>> Via btmon I was able to dump data from this channel 65 and via some
> >>> sed/perl magic I converted received voice data and played it:
> >>> 
> >>> $ btmon > /tmp/dump
> >>> CTRL+C
> >>> $ grep 'Channel: 65' -A 14 /tmp/dump | grep '^        ' | sed 's/^        //;s/  .*//' | tr ' ' '\n' | perl -ne 'print chr(hex($_))' > /tmp/voice.sbc
> >>> $ sbcdec -f /tmp/voice.snd /tmp/voice.sbc
> >>> $ play /tmp/voice.snd
> >>> 
> >>> And I heard clear voice. So FastStream is really just rebranded SBC
> >>> codec (with fixed parameters; without RTP) and in A2DP bluetooth profile
> >>> provides nice bi-directional channels.
> >> 
> >> can you show us at least a few of these channel 65 frames from btmon decoding. If it is via L2CAP fixed PSM, then in theory there needs to be some sort of channel establishment. Or if this via L2CAP fixed CID, then it is essentially unicast connectionless data. Both can be handled via L2CAP sockets, but you need to create sockets for these to receive the data.
> >> 
> >> On a side note, fixed CID 65 and fixed PSM 65 are both Bluetooth SIG reserved values, so seems like this codec is still violating the standard.
> > 
> > Hi! In attachment is btmon dump with codec negotiation, connect, both
> > sink and source data and disconnect. Interesting is that now channel 65
> > is used for both sink and source. Yesterday when I was doing tests I
> > remember that different channel was used for microphone input and audio
> > playback.
> 
> so the Channel: 65 is a CID and is assigned dynamically. They can be different in each direction and by chance you get Source CID: 65 and Destination CID: 65. What I am seeing is that you get TX and RX on that PSM 25 which seems to be the established media channel. This means the file descriptor you already have for sending audio, just read from it and you should be getting the back channel receiving audio. L2CAP channels are always bi-directional.

Interesting. Now I repeated my tests again and channels 77 and 64 are
used (64 for voice microphone). Just in case, btmon output is attached.

I would try to read directly from file descriptor used for sending data
and see if I can easily decode it in pulseaudio. As sbcdec was able to
decode it I hope that there would not be problem with libsbc in
pulseaudio.

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

[-- Attachment #1.2: btmon2.gz --]
[-- Type: application/gzip, Size: 122644 bytes --]

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

Re: bluez: A2DP backchannel

[Marcel Holtmann]

Hi Pali,

>>>>>>>> Some vendor A2DP bluetooth codecs like FastStream or aptX Low Latency
>>>>>>>> supports backchannel. Which means that they are bi-directional and in
>>>>>>>> A2DP they supports not only (music) playback, but also receiving
>>>>>>>> backchannel (microphone) voice.
>>>>>>>> 
>>>>>>>> How to establish this bi-directional A2DP transfer with backchannel via
>>>>>>>> bluez daemon?
>>>>>>> 
>>>>>>> There is no such thing as bi-directional in AVDTP, which is a screw up
>>>>>>> from the spec authors,
>>>>>> 
>>>>>> So it means that those vendor A2DP codecs somehow extends AVDTP, right?
>>>>>> I would need to figure out how A2DP devices send voice data... At least
>>>>>> backchannel activation for FastStream is via one bit in codec parameters
>>>>>> like other codec parameters.
>>>>>> 
>>>>>>> luckily we don't have to stick to it since our
>>>>>>> sockets are bi-directional so you can send and receive data at same
>>>>>>> time, though the configuration must be the same in either direction
>>>>>>> otherwise we would have to support transport multiplexing to have
>>>>>>> multiple configuration done using the same channel.
>>>>>> 
>>>>>> So does it mean that I can read from file descriptor received from dbus
>>>>>> which is used for sending encoded A2DP audio samples? And if other side
>>>>>> (e.g device with FastStream or aptX LL vendor codec) send voice via A2DP
>>>>>> then I receive them on that file descriptor?
>>>>> 
>>>>> Now I established A2DP connection with FastStream codec and in btmon I
>>>>> see that my headset started sending some data to channel 65 in this A2DP
>>>>> mode.
>>>>> 
>>>>> So definitely it is possible to send data from headset to computer (that
>>>>> backchannel) in A2DP mode despite what A2DP specification says.
>>>>> 
>>>>> I managed to modify pulseaudio code to start encoding and streaming
>>>>> FastStream data to headset and it is working.
>>>>> 
>>>>> Now the challenge would be how to get those data which headset send to
>>>>> channel 65? Is bluez really sending them via file descriptor which is
>>>>> used for writing from host to headset?
>>>>> 
>>>>> Via btmon I was able to dump data from this channel 65 and via some
>>>>> sed/perl magic I converted received voice data and played it:
>>>>> 
>>>>> $ btmon > /tmp/dump
>>>>> CTRL+C
>>>>> $ grep 'Channel: 65' -A 14 /tmp/dump | grep '^        ' | sed 's/^        //;s/  .*//' | tr ' ' '\n' | perl -ne 'print chr(hex($_))' > /tmp/voice.sbc
>>>>> $ sbcdec -f /tmp/voice.snd /tmp/voice.sbc
>>>>> $ play /tmp/voice.snd
>>>>> 
>>>>> And I heard clear voice. So FastStream is really just rebranded SBC
>>>>> codec (with fixed parameters; without RTP) and in A2DP bluetooth profile
>>>>> provides nice bi-directional channels.
>>>> 
>>>> can you show us at least a few of these channel 65 frames from btmon decoding. If it is via L2CAP fixed PSM, then in theory there needs to be some sort of channel establishment. Or if this via L2CAP fixed CID, then it is essentially unicast connectionless data. Both can be handled via L2CAP sockets, but you need to create sockets for these to receive the data.
>>>> 
>>>> On a side note, fixed CID 65 and fixed PSM 65 are both Bluetooth SIG reserved values, so seems like this codec is still violating the standard.
>>> 
>>> Hi! In attachment is btmon dump with codec negotiation, connect, both
>>> sink and source data and disconnect. Interesting is that now channel 65
>>> is used for both sink and source. Yesterday when I was doing tests I
>>> remember that different channel was used for microphone input and audio
>>> playback.
>> 
>> so the Channel: 65 is a CID and is assigned dynamically. They can be different in each direction and by chance you get Source CID: 65 and Destination CID: 65. What I am seeing is that you get TX and RX on that PSM 25 which seems to be the established media channel. This means the file descriptor you already have for sending audio, just read from it and you should be getting the back channel receiving audio. L2CAP channels are always bi-directional.
> 
> Interesting. Now I repeated my tests again and channels 77 and 64 are
> used (64 for voice microphone). Just in case, btmon output is attached.

that is fine. As I said, different CID numbers are assigned for each direction. They are negotiated when the L2CAP channel is created. That they are the same rarely happens, but it can. Anyhow, the L2CAP socket from the kernel will map CID 64 into recv and CID 77 into send.

> I would try to read directly from file descriptor used for sending data
> and see if I can easily decode it in pulseaudio. As sbcdec was able to
> decode it I hope that there would not be problem with libsbc in
> pulseaudio.

No idea why it would be SBC encoded, but sure. I don’t know enough detail about Fast Stream codec.

Regards

Marcel

Re: bluez: A2DP backchannel

[Pali Rohár]

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

On Monday 30 July 2018 21:39:09 Marcel Holtmann wrote:
> Hi Pali,
> 
> >>>>>>>> Some vendor A2DP bluetooth codecs like FastStream or aptX Low Latency
> >>>>>>>> supports backchannel. Which means that they are bi-directional and in
> >>>>>>>> A2DP they supports not only (music) playback, but also receiving
> >>>>>>>> backchannel (microphone) voice.
> >>>>>>>> 
> >>>>>>>> How to establish this bi-directional A2DP transfer with backchannel via
> >>>>>>>> bluez daemon?
> >>>>>>> 
> >>>>>>> There is no such thing as bi-directional in AVDTP, which is a screw up
> >>>>>>> from the spec authors,
> >>>>>> 
> >>>>>> So it means that those vendor A2DP codecs somehow extends AVDTP, right?
> >>>>>> I would need to figure out how A2DP devices send voice data... At least
> >>>>>> backchannel activation for FastStream is via one bit in codec parameters
> >>>>>> like other codec parameters.
> >>>>>> 
> >>>>>>> luckily we don't have to stick to it since our
> >>>>>>> sockets are bi-directional so you can send and receive data at same
> >>>>>>> time, though the configuration must be the same in either direction
> >>>>>>> otherwise we would have to support transport multiplexing to have
> >>>>>>> multiple configuration done using the same channel.
> >>>>>> 
> >>>>>> So does it mean that I can read from file descriptor received from dbus
> >>>>>> which is used for sending encoded A2DP audio samples? And if other side
> >>>>>> (e.g device with FastStream or aptX LL vendor codec) send voice via A2DP
> >>>>>> then I receive them on that file descriptor?
> >>>>> 
> >>>>> Now I established A2DP connection with FastStream codec and in btmon I
> >>>>> see that my headset started sending some data to channel 65 in this A2DP
> >>>>> mode.
> >>>>> 
> >>>>> So definitely it is possible to send data from headset to computer (that
> >>>>> backchannel) in A2DP mode despite what A2DP specification says.
> >>>>> 
> >>>>> I managed to modify pulseaudio code to start encoding and streaming
> >>>>> FastStream data to headset and it is working.
> >>>>> 
> >>>>> Now the challenge would be how to get those data which headset send to
> >>>>> channel 65? Is bluez really sending them via file descriptor which is
> >>>>> used for writing from host to headset?
> >>>>> 
> >>>>> Via btmon I was able to dump data from this channel 65 and via some
> >>>>> sed/perl magic I converted received voice data and played it:
> >>>>> 
> >>>>> $ btmon > /tmp/dump
> >>>>> CTRL+C
> >>>>> $ grep 'Channel: 65' -A 14 /tmp/dump | grep '^        ' | sed 's/^        //;s/  .*//' | tr ' ' '\n' | perl -ne 'print chr(hex($_))' > /tmp/voice.sbc
> >>>>> $ sbcdec -f /tmp/voice.snd /tmp/voice.sbc
> >>>>> $ play /tmp/voice.snd
> >>>>> 
> >>>>> And I heard clear voice. So FastStream is really just rebranded SBC
> >>>>> codec (with fixed parameters; without RTP) and in A2DP bluetooth profile
> >>>>> provides nice bi-directional channels.
> >>>> 
> >>>> can you show us at least a few of these channel 65 frames from btmon decoding. If it is via L2CAP fixed PSM, then in theory there needs to be some sort of channel establishment. Or if this via L2CAP fixed CID, then it is essentially unicast connectionless data. Both can be handled via L2CAP sockets, but you need to create sockets for these to receive the data.
> >>>> 
> >>>> On a side note, fixed CID 65 and fixed PSM 65 are both Bluetooth SIG reserved values, so seems like this codec is still violating the standard.
> >>> 
> >>> Hi! In attachment is btmon dump with codec negotiation, connect, both
> >>> sink and source data and disconnect. Interesting is that now channel 65
> >>> is used for both sink and source. Yesterday when I was doing tests I
> >>> remember that different channel was used for microphone input and audio
> >>> playback.
> >> 
> >> so the Channel: 65 is a CID and is assigned dynamically. They can be different in each direction and by chance you get Source CID: 65 and Destination CID: 65. What I am seeing is that you get TX and RX on that PSM 25 which seems to be the established media channel. This means the file descriptor you already have for sending audio, just read from it and you should be getting the back channel receiving audio. L2CAP channels are always bi-directional.
> > 
> > Interesting. Now I repeated my tests again and channels 77 and 64 are
> > used (64 for voice microphone). Just in case, btmon output is attached.
> 
> that is fine. As I said, different CID numbers are assigned for each direction. They are negotiated when the L2CAP channel is created. That they are the same rarely happens, but it can. Anyhow, the L2CAP socket from the kernel will map CID 64 into recv and CID 77 into send.

Ok.

> > I would try to read directly from file descriptor used for sending data
> > and see if I can easily decode it in pulseaudio. As sbcdec was able to
> > decode it I hope that there would not be problem with libsbc in
> > pulseaudio.
> 
> No idea why it would be SBC encoded, but sure. I don’t know enough detail about Fast Stream codec.

From information which I have:

FastStream A2DP codec for audio sink uses SBC codec without RTP wrapping
with following parameters: frequency rate 44.1 kHz or 48 Hz, Block 16,
Sub-bands 8, Joint Stereo, Loudness and Bitpool 29. Data rate is 212
kbps, packet size 72*3+4 = 220. DSP decoders round 71 bytes to 72 (that
is why sbc size in packet is 72 and not 71). FastStream is presented as
low latency A2DP codec; but it is just rebranded SBC codec with fixes
parameters.

Backchannel in FastStream A2DP codec uses SBC codec too with parameters:
frequency rate 16 kHz, Blocks 16, Sub-bands 8, Mono, Loudness, Bitpool
32. Data rate is 72 kbps, packet size 72*3+4 = 220. Again 71 bytes are
rounded to 72 in DSP.

I do not know yet what should be stored on that 72. byte. When I put
there zero byte, my headset is happy and play music without glitches
(This zero byte can be seen also in dumps which I sent). But received
voice data seems to always have different value on that position. So I
guess it could be some checksum...

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

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

Re: bluez: A2DP backchannel

[Luiz Augusto von Dentz]

Hi Marcel,

On Mon, Jul 30, 2018 at 10:39 PM, Marcel Holtmann <marcel@holtmann.org> wro=
te:
> Hi Pali,
>
>>>>>>>>> Some vendor A2DP bluetooth codecs like FastStream or aptX Low Lat=
ency
>>>>>>>>> supports backchannel. Which means that they are bi-directional an=
d in
>>>>>>>>> A2DP they supports not only (music) playback, but also receiving
>>>>>>>>> backchannel (microphone) voice.
>>>>>>>>>
>>>>>>>>> How to establish this bi-directional A2DP transfer with backchann=
el via
>>>>>>>>> bluez daemon?
>>>>>>>>
>>>>>>>> There is no such thing as bi-directional in AVDTP, which is a scre=
w up
>>>>>>>> from the spec authors,
>>>>>>>
>>>>>>> So it means that those vendor A2DP codecs somehow extends AVDTP, ri=
ght?
>>>>>>> I would need to figure out how A2DP devices send voice data... At l=
east
>>>>>>> backchannel activation for FastStream is via one bit in codec param=
eters
>>>>>>> like other codec parameters.
>>>>>>>
>>>>>>>> luckily we don't have to stick to it since our
>>>>>>>> sockets are bi-directional so you can send and receive data at sam=
e
>>>>>>>> time, though the configuration must be the same in either directio=
n
>>>>>>>> otherwise we would have to support transport multiplexing to have
>>>>>>>> multiple configuration done using the same channel.
>>>>>>>
>>>>>>> So does it mean that I can read from file descriptor received from =
dbus
>>>>>>> which is used for sending encoded A2DP audio samples? And if other =
side
>>>>>>> (e.g device with FastStream or aptX LL vendor codec) send voice via=
 A2DP
>>>>>>> then I receive them on that file descriptor?
>>>>>>
>>>>>> Now I established A2DP connection with FastStream codec and in btmon=
 I
>>>>>> see that my headset started sending some data to channel 65 in this =
A2DP
>>>>>> mode.
>>>>>>
>>>>>> So definitely it is possible to send data from headset to computer (=
that
>>>>>> backchannel) in A2DP mode despite what A2DP specification says.
>>>>>>
>>>>>> I managed to modify pulseaudio code to start encoding and streaming
>>>>>> FastStream data to headset and it is working.
>>>>>>
>>>>>> Now the challenge would be how to get those data which headset send =
to
>>>>>> channel 65? Is bluez really sending them via file descriptor which i=
s
>>>>>> used for writing from host to headset?
>>>>>>
>>>>>> Via btmon I was able to dump data from this channel 65 and via some
>>>>>> sed/perl magic I converted received voice data and played it:
>>>>>>
>>>>>> $ btmon > /tmp/dump
>>>>>> CTRL+C
>>>>>> $ grep 'Channel: 65' -A 14 /tmp/dump | grep '^        ' | sed 's/^  =
      //;s/  .*//' | tr ' ' '\n' | perl -ne 'print chr(hex($_))' > /tmp/voi=
ce.sbc
>>>>>> $ sbcdec -f /tmp/voice.snd /tmp/voice.sbc
>>>>>> $ play /tmp/voice.snd
>>>>>>
>>>>>> And I heard clear voice. So FastStream is really just rebranded SBC
>>>>>> codec (with fixed parameters; without RTP) and in A2DP bluetooth pro=
file
>>>>>> provides nice bi-directional channels.
>>>>>
>>>>> can you show us at least a few of these channel 65 frames from btmon =
decoding. If it is via L2CAP fixed PSM, then in theory there needs to be so=
me sort of channel establishment. Or if this via L2CAP fixed CID, then it i=
s essentially unicast connectionless data. Both can be handled via L2CAP so=
ckets, but you need to create sockets for these to receive the data.
>>>>>
>>>>> On a side note, fixed CID 65 and fixed PSM 65 are both Bluetooth SIG =
reserved values, so seems like this codec is still violating the standard.
>>>>
>>>> Hi! In attachment is btmon dump with codec negotiation, connect, both
>>>> sink and source data and disconnect. Interesting is that now channel 6=
5
>>>> is used for both sink and source. Yesterday when I was doing tests I
>>>> remember that different channel was used for microphone input and audi=
o
>>>> playback.
>>>
>>> so the Channel: 65 is a CID and is assigned dynamically. They can be di=
fferent in each direction and by chance you get Source CID: 65 and Destinat=
ion CID: 65. What I am seeing is that you get TX and RX on that PSM 25 whic=
h seems to be the established media channel. This means the file descriptor=
 you already have for sending audio, just read from it and you should be ge=
tting the back channel receiving audio. L2CAP channels are always bi-direct=
ional.
>>
>> Interesting. Now I repeated my tests again and channels 77 and 64 are
>> used (64 for voice microphone). Just in case, btmon output is attached.
>
> that is fine. As I said, different CID numbers are assigned for each dire=
ction. They are negotiated when the L2CAP channel is created. That they are=
 the same rarely happens, but it can. Anyhow, the L2CAP socket from the ker=
nel will map CID 64 into recv and CID 77 into send.
>
>> I would try to read directly from file descriptor used for sending data
>> and see if I can easily decode it in pulseaudio. As sbcdec was able to
>> decode it I hope that there would not be problem with libsbc in
>> pulseaudio.
>
> No idea why it would be SBC encoded, but sure. I don=E2=80=99t know enoug=
h detail about Fast Stream codec.

It appears Fast Strem uses SBC in both directions, though this is not
'supported' in AVDTP since endpoint can only be source or sink, not
both and having both ways configure would require 2 channels but
apparently they got away with L2CAP being bi-directional. The input
side is most like mSBC so they don't have to configure anything since
mSBC uses fixed parameters.

> Regards
>
> Marcel
>



--=20
Luiz Augusto von Dentz