From: Trent Piepho <tpiepho@gmail.com>
To: "Pali Rohár" <pali@kernel.org>
Cc: Joseph Hwang <josephsih@google.com>,
linux-bluetooth <linux-bluetooth@vger.kernel.org>,
Marcel Holtmann <marcel@holtmann.org>,
Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
chromeos-bluetooth-upstreaming
<chromeos-bluetooth-upstreaming@chromium.org>,
Alain Michaud <alainm@chromium.org>,
Abhishek Pandit-Subedi <abhishekpandit@chromium.org>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Johan Hedberg <johan.hedberg@gmail.com>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH v3 1/2] Bluetooth: btusb: define HCI packet sizes of USB Alts
Date: Wed, 09 Dec 2020 16:19:39 -0800 [thread overview]
Message-ID: <5703442.lOV4Wx5bFT@zen.local> (raw)
In-Reply-To: <20201209011336.4qdnnehnz3kdlqid@pali>
On Tuesday, December 8, 2020 5:13:36 PM PST Pali Rohár wrote:
> On Tuesday 08 December 2020 15:04:29 Trent Piepho wrote:
> > Does this also give userspace a clear point at which to determine MTU
setting,
> > _before_ data is sent over SCO connection? It will not work if sco_mtu
is not
> > valid until after userspace sends data to SCO connection with incorrect
mtu.
>
> IIRC connection is established after sync connection (SCO) complete
> event. And sending data is possible after connection is established. So
> based on these facts I think that userspace can determinate MTU settings
> prior sending data over SCO socket.
>
> Anyway, to whole MTU issue for SCO there is a nice workaround which
> worked fine with more tested USB adapters and headsets. As SCO socket is
> synchronous and most bluetooth headsets have own clocks, you can
> synchronize sending packets to headsets based on time events when you
> received packets from other side and also send packets of same size as
> you received. I.e. for every received packet send own packet of the same
> size.
As I understand it, the RX side from the headset is not guaranteed, so in
the TX only case this will not work and we still need to be told what MTU
kernel has selected for the SCO link.
It seems also it would add some latency to start up, since it would be
necessary to wait for packets to arrive before knowing what size packet to
send.
Would timing based on matching TX to RX in the case of packet loss on RX
side?
next prev parent reply other threads:[~2020-12-10 0:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-10 6:04 [PATCH v3 0/2] To support the HFP WBS, a chip vendor may choose a particular Joseph Hwang
2020-09-10 6:04 ` [PATCH v3 1/2] Bluetooth: btusb: define HCI packet sizes of USB Alts Joseph Hwang
2020-09-10 8:18 ` Pali Rohár
2020-09-14 12:18 ` Joseph Hwang
2020-09-23 10:22 ` Pali Rohár
2020-12-08 23:04 ` Trent Piepho
2020-12-09 1:13 ` Pali Rohár
2020-12-10 0:19 ` Trent Piepho [this message]
2020-12-10 0:35 ` Pali Rohár
2020-09-10 6:04 ` [PATCH v3 2/2] Bluetooth: sco: new getsockopt options BT_SNDMTU/BT_RCVMTU Joseph Hwang
2020-09-10 8:20 ` Pali Rohár
2020-09-11 7:08 ` Marcel Holtmann
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=5703442.lOV4Wx5bFT@zen.local \
--to=tpiepho@gmail.com \
--cc=abhishekpandit@chromium.org \
--cc=alainm@chromium.org \
--cc=chromeos-bluetooth-upstreaming@chromium.org \
--cc=davem@davemloft.net \
--cc=johan.hedberg@gmail.com \
--cc=josephsih@google.com \
--cc=kuba@kernel.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=marcel@holtmann.org \
--cc=netdev@vger.kernel.org \
--cc=pali@kernel.org \
/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.