From: Marcel Holtmann <marcel@holtmann.org>
To: "Pali Rohár" <pali.rohar@gmail.com>
Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
"linux-bluetooth@vger.kernel.org"
<linux-bluetooth@vger.kernel.org>
Subject: Re: bluez: A2DP backchannel
Date: Mon, 30 Jul 2018 13:05:33 +0200 [thread overview]
Message-ID: <4BA0F4BA-1CA9-46F1-8A86-212321742D4B@holtmann.org> (raw)
In-Reply-To: <20180728192649.7aryivyczpr2ek47@pali>
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
next prev parent reply other threads:[~2018-07-30 11:05 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-11 11:04 bluez: A2DP backchannel Pali Rohár
2018-07-11 13:34 ` Luiz Augusto von Dentz
2018-07-11 14:37 ` Pali Rohár
2018-07-28 19:26 ` Pali Rohár
2018-07-30 11:05 ` Marcel Holtmann [this message]
2018-07-30 17:10 ` Pali Rohár
2018-07-30 18:15 ` Marcel Holtmann
2018-07-30 18:25 ` Pali Rohár
2018-07-30 19:39 ` Marcel Holtmann
2018-07-30 19:53 ` Pali Rohár
2018-07-30 19:54 ` Luiz Augusto von Dentz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BA0F4BA-1CA9-46F1-8A86-212321742D4B@holtmann.org \
--to=marcel@holtmann.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=pali.rohar@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.