Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20190518190618.m7rdkthvpz4agxd2@pali>
In-Reply-To: <20190518190618.m7rdkthvpz4agxd2@pali>
From:   Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date:   Sun, 19 May 2019 11:13:09 +0300
Message-ID: <CABBYNZ+8YX-zBnUaYKLX2=OdJ-GUQ4y4V0EhGsN+uecKEpFBeA@mail.gmail.com>
Subject: Re: bluez A2DP socket reliability
To:     =?UTF-8?Q?Pali_Roh=C3=A1r?= <pali.rohar@gmail.com>
Cc:     "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Pali,

On Sat, May 18, 2019 at 11:12 PM Pali Roh=C3=A1r <pali.rohar@gmail.com> wro=
te:
>
> 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.


--=20
Luiz Augusto von Dentz