Hi,
Le 10/06/2019 à 12:51, Pali Rohár a écrit :
On Friday 07 June 2019 18:23:41 Luiz Augusto von Dentz wrote:
Hi Pali,
On Fri, Jun 7, 2019 at 4:00 PM Pali Rohár<pali.rohar@xxxxxxxxx> wrote:
On Sunday 19 May 2019 14:22:23 Pali Rohár wrote:
On Sunday 19 May 2019 11:13:09 Luiz Augusto von Dentz wrote:
Hi Pali,
On Sat, May 18, 2019 at 11:12 PM Pali Rohár<pali.rohar@xxxxxxxxx> wrote:
Hello! How is L2CAP layer of bluetooth socket used for A2DP audio
transfer configured in bluez? It is reliable with big/infinite
retransmit count? Or in best-effort manner and some packets may be
dropped? And it is possible to change between these two modes for
application which uses bluez DBUS API? I'm asking because some A2DP
audio codecs are designed to deal with packet loss and for those codecs
it would be probably better to configure L2CAP socket to unreliable
mode.
We don't use ERTM with AVDTP, both signaling and transport sockets are
using basic mode which don't support retransmissions, there the
concept of flush timeout which iirc we don't currently it.
On bluez.org site there is no information how to use bluez sockets and
the only documentation/tutorial which I found on internet was this:
https://people.csail.mit.edu/albert/bluez-intro/x559.html
I do not know how up-to-date it is, but seems that by default bluez
L2CAP sockets are reliable and to change them to unreliable mode it is
needed to issue OGF_HOST_CTL / OCF_WRITE_AUTOMATIC_FLUSH_TIMEOUT (0x28)
request. As default is zero = infinity = reliable connection.
I do not understand low level bluetooth details, but is ERTM related to
OCF_WRITE_AUTOMATIC_FLUSH_TIMEOUT?
So what are default settings for L2CAP socket used by AVDTP/A2DP
profiles which are transferred to user application via DBUS?
Hi! Do you have any idea about OCF_WRITE_AUTOMATIC_FLUSH_TIMEOUT? It is
related to ERTM or not?
The OCF usually describes an HCI command which may affect the entire
ACL connection, ERTM is a L2CAP channel mode that includes
retransmissions. The A2DP stream transport doesn't ERTM so no
retransmissions shall take place.
Fine, no retransmission is good for A2DP.
I am not sure there is no retransmission with current implementation.
AFAIU, ERTM and automatic flush timeout are not linked. ERTM operates at
L2CAP level while automatic flush timeout [1] operates at ACL level.
When I read the automatic flush timeout set for an A2DP SBC connection
it returns 0, which means that the connection uses an infinite timeout.
So, even if higher levels set packets as flushable, the ACL policy
requests baseband to indefinitely try to send data [3]:
"The default Flush Timeout shall be infinite,
i.e. re-transmissions are carried out until
physical link loss occurs. This is also
referred to as a 'reliable channel.'"
[1] Bluetooth core Vol 2, Part E, 6.19
[2] Bluetooth core Vol 2, Part E, 7.3.29
[3] Bluetooth core Vol 2, Part B, 7.6.3
--
Frédéric Danis Embedded Linux Consultant
frederic.danis.oss@xxxxxxxxx
