linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sathish Narasimman <nsathish41@gmail.com>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: chethan tn <chethantn@gmail.com>,
	Bluez mailing list <linux-bluetooth@vger.kernel.org>,
	Chethan T N <chethan.tumkur.narayan@intel.com>,
	Sathish Narasimman <sathish.narasimman@intel.com>,
	Sathish N <nsathish41@gmail.com>
Subject: Re: L2CAP mtu preference set by user space clarification
Date: Tue, 28 Jan 2020 12:31:53 +0530	[thread overview]
Message-ID: <CAOVXEJKb-BNz_Y2xFnEcsiGYgZMaTEYjqrspw1TgCdsFgYNESQ@mail.gmail.com> (raw)
In-Reply-To: <CABBYNZLW7qe8ie-FLYaka7wKTeKAmBQYf0DG0ZZqbOu2eEOxPA@mail.gmail.com>

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.


On Wed, Dec 18, 2019 at 5:49 AM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
>
> Hi Chethan,
>
> On Mon, Dec 16, 2019 at 10:40 PM chethan tn <chethantn@gmail.com> 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

  reply	other threads:[~2020-01-28  7:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-17  6:36 L2CAP mtu preference set by user space clarification chethan tn
2019-12-18  0:19 ` Luiz Augusto von Dentz
2020-01-28  7:01   ` Sathish Narasimman [this message]
2020-01-30  5:19     ` Sathish Narasimman
2020-01-30 19:12     ` Luiz Augusto von Dentz
2020-01-31  5:07       ` Sathish Narasimman

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=CAOVXEJKb-BNz_Y2xFnEcsiGYgZMaTEYjqrspw1TgCdsFgYNESQ@mail.gmail.com \
    --to=nsathish41@gmail.com \
    --cc=chethan.tumkur.narayan@intel.com \
    --cc=chethantn@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    --cc=sathish.narasimman@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).