Hi Luiz Thanks for the suggestion. On Fri, Jan 31, 2020 at 12:42 AM Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > > Hi Sathish, > > On Mon, Jan 27, 2020 at 11:02 PM Sathish Narasimman > <nsathish41@xxxxxxxxx> wrote: > > > > Hi Luiz, > > > > There are some headsets that configure the MTU to 850(3M PHY) and then > > under some situation(noisy), it switches to 2M PHY packets for A2DP > > playback. The reason behind this is their receiver's capability for > > better demodulation with QDPSK(2M PHY) when compared to 8DPSK(3M PHY). > > > > From Bluetooth specification, the remote device can request the > > LMP_preferred_rate with the LMP command to switch to 2M. When Baseband > > PHY is 2M, the maximum possible packet type is 2DH5 which can hold > > 679 bytes ( 672 bytes of L2CAP MTU excluding the baseband headers). > > > > When L2CAP MTU for an A2DP packet is larger than 672 bytes, it happens > > to use 2 Baseband packets to deliver the L2CAP packet ie., like 1 > > 2DH5(679 bytes) and 1 2DH3(171 bytes) packet to deliver 850 bytes of > > AVDTP Media. The is not efficient baseband utilization when the number > > of baseband ACL buffers used 2 no.s or even less that may lead to the > > delivery of one L2CAP packet that may take 4 slots more ( 2.5 ms > > more). > > > > When the remote device ( headset) has less number of baseband ACL > > buffers and Host(source) is aggressively delivering the audio data to > > render, it shall end up in a condition where the remote device does > > Flow OFF that shall make the Source device to wait until next FLOW ON > > send from the headset device. This kind of situation shall end up > > accumulating more buffers and FLOW ON/OFF become cyclic and leads to > > an audio break. > > > > Is there a better solution to overcome this issue? > > > > We considered changing the HOST MTU to 672bytes to overcome this issue > > that makes the remote headset device to use 2M. And found that the > > test results are positive. > > But we only control the RX/input MTU not the TX/output MTU, so the > headset is at fault here it should have reconfigured the MTU > accordingly. For the RX/input there is a patch already adjusting the > MTU automatically when the socket MTU is set to 0: > > commit 4b6e228e297b73451f3a4b12fb7d0b24d9d32e6f > Author: Luiz Augusto von Dentz <luiz.von.dentz@xxxxxxxxx> > Date: Thu Jan 2 15:00:57 2020 -0800 > > Bluetooth: Auto tune if input MTU is set to 0 > > This enables the code to set the input MTU using the underline link > packet types when set to 0, previously this would likely be rejected by > the remote peer since it would be bellow the minimal of 48 for BR/EDR > or 23 for LE, that way it shall be safe to use 0 without causing any > side effects. > > This is convenient for the likes of A2DP transport, see: > > https://habr.com/en/post/456182/ > > Without the remote side updating the MTU the host has no idea of the > changes to the packet type, also we would have to notify the upper > layer of the change if that happens mid stream, this relation between > packet type is not very clear to the L2CAP layer since it doesn't > distinct what data the upper layer is sending so we cannot just do the > MTU change locally and limit the output MTU based on the underline > link, expect perhaps if we would be willing to do that when MTU is set > to 0 in which we would artificially limit the packet length based on > the supported packet types, but does the controller notifies this sort > of change to the host at all? > > > > > On Wed, Dec 18, 2019 at 5:49 AM Luiz Augusto von Dentz > > <luiz.dentz@xxxxxxxxx> wrote: > > > > > > Hi Chethan, > > > > > > On Mon, Dec 16, 2019 at 10:40 PM chethan tn <chethantn@xxxxxxxxx> wrote: > > > > > > > > Hi, > > > > > > > > I would like to understand why the Source device L2CAP mtu is always > > > > set to the remote device mtu during L2CAP connection? > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/tree/net/bluetooth/l2cap_core.c#n3370 > > > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/tree/net/bluetooth/l2cap_core.c#n3474 > > > > > > > > > > > > > > > > I tried to set the specific MTU for specific profile connection( For > > > > Ex: A2DP connection - PSM 25) patch mentioned below, but the same is > > > > not reflected because of the below code. > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/tree/net/bluetooth/l2cap_core.c#n3474 > > > > > > The answer is pretty simple, we don't control the remote/output MTU, > > > so we cannot force the remote to use some arbitrary MTU if it doesn't > > > agree with. > > > > > > > Here the patch to set the MTU from the use space bluez. > > > > > > > > diff --git a/profiles/audio/a2dp.c b/profiles/audio/a2dp.c > > > > index 58e1534a4..7d8a718c0 100644 > > > > --- a/profiles/audio/a2dp.c > > > > +++ b/profiles/audio/a2dp.c > > > > @@ -1573,6 +1573,7 @@ static bool a2dp_server_listen(struct a2dp_server *server) > > > > BT_IO_OPT_SOURCE_BDADDR, > > > > btd_adapter_get_address(server->adapter), > > > > BT_IO_OPT_PSM, AVDTP_PSM, > > > > + BT_IO_OPT_OMTU, AVDTP_MTU, > > > > BT_IO_OPT_SEC_LEVEL, BT_IO_SEC_MEDIUM, > > > > BT_IO_OPT_MASTER, true, > > > > BT_IO_OPT_INVALID); > > > > diff --git a/profiles/audio/avdtp.c b/profiles/audio/avdtp.c > > > > index 51ead684a..786702cec 100644 > > > > --- a/profiles/audio/avdtp.c > > > > +++ b/profiles/audio/avdtp.c > > > > @@ -2394,6 +2394,7 @@ static GIOChannel *l2cap_connect(struct avdtp *session) > > > > BT_IO_OPT_DEST_BDADDR, > > > > device_get_address(session->device), > > > > BT_IO_OPT_PSM, AVDTP_PSM, > > > > + BT_IO_OPT_OMTU, AVDTP_MTU, > > > > BT_IO_OPT_SEC_LEVEL, BT_IO_SEC_MEDIUM, > > > > BT_IO_OPT_INVALID); > > > > if (!io) { > > > > diff --git a/profiles/audio/avdtp.h b/profiles/audio/avdtp.h > > > > index 621a6e3cf..372b2579d 100644 > > > > --- a/profiles/audio/avdtp.h > > > > +++ b/profiles/audio/avdtp.h > > > > > > > > > > > > > > > > Can you please suggest what is the best way to set the L2CAP mtu as > > > > user defined. > > > > > > > > > > > > Thanks > > > > > > > > Chethan > > > > > > > > > > > > -- > > > Luiz Augusto von Dentz > > > > Regards > > Sathish N > > > > -- > Luiz Augusto von Dentz
