Linux-Bluetooth Archive on lore.kernel.org
 help / color / Atom feed
From: "Pali Rohár" <pali.rohar@gmail.com>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
	Brian Gix <brian.gix@intel.com>,
	"iam@valdikss.org.ru" <iam@valdikss.org.ru>,
	"linux-bluetooth@vger.kernel.org"
	<linux-bluetooth@vger.kernel.org>
Subject: Re: Determinate EDR speed
Date: Wed, 16 Oct 2019 21:13:43 +0200
Message-ID: <20191016191343.clby7pmkdq3q2i7s@pali> (raw)
In-Reply-To: <FE2F255A-6762-485B-9166-8348CFB18168@holtmann.org>

[-- Attachment #1: Type: text/plain, Size: 5651 bytes --]

On Wednesday 16 October 2019 21:06:41 Marcel Holtmann wrote:
> Hi Pali,
> 
> >>>>>>>> Currently bluez API, method Acquire() already inform called application
> >>>>>>>> what is socket MTU for input and output. So from this information it is
> >>>>>>>> possible to detect if device supports EDR 3 or not.
> >>>>>>>> 
> >>>>>>>> But it is too late to have this information. I need to send SBC
> >>>>>>>> parameters to bluez first when doing A2DP negotiation, this is early
> >>>>>>>> steps before Acquire() is called.
> >>>>>>> 
> >>>>>>> This seems to be the kind of information which is fixed, for the life of the pairing.
> >>>>>>> 
> >>>>>>> What if you assumed the lower speed the first time you connected, determined the
> >>>>>>> speed during the first streaming, and then either immediately renegotiate (caching the identifying
> >>>>>>> information
> >>>>>>> of the SNK), or just cache the information for future connections.
> >>>>>>> 
> >>>>>>> Or the reverse, and assume fast, but immediately adjust down if you aren't getting what you hoped for.
> >>>>>>> 
> >>>>>>> In any case, this would be a "Device Setup" glitch which you could note as a routine part of pairing in the
> >>>>>>> documentation.
> >>>>>> 
> >>>>>> Or, Stream "Silence" the first time you connect, in order to determine throughput.  It would add 1-2 seconds to
> >>>>>> your connection time perhaps, but would be less noticable to the user.
> >>>>> 
> >>>>> This increase connection time, increase complexity of implementation
> >>>>> (lot of things can fail) and just complicate lot of things there. Plus
> >>>>> adds that glitch which is not user friendly.
> >>>>> 
> >>>>> Also bluetooth devices, like headsets, probably do not expects that
> >>>>> somebody is going to do such thing and we can hit other implementation
> >>>>> problems...
> >>>>> 
> >>>>> And moreover it is just big hack and workaround for that problem. Not a
> >>>>> reasonable solution.
> >>>>> 
> >>>>> In btmon I can see it, so kernel already knows that information. Why it
> >>>>> cannot tell it to userspace and bluetooth daemon to client application?
> >>>>> 
> >>>>> Client application (e.g. pulseaudio) should really know if is going to
> >>>>> talk with bluetooth device with EDR 2 or EDR 3.
> >>>>> 
> >>>>>>> 
> >>>>>>>> Therefore I'm asking for some way how to get information if device
> >>>>>>>> supports EDR 2 or EDR 3. This is basically requirement for proper
> >>>>>>>> implementation of SBC in high quality mode. So if there are not such API
> >>>>>>>> yet, could it be exported from kernel to userspace and bluetoothd
> >>>>>>>> daemon?
> >>>>>>>> 
> >>>>>>>> See these two articles for more details about SBC and its high quality:
> >>>>>>>> 
> >>>>>>>> https://habr.com/en/post/456182/
> >>>>>>>> http://soundexpert.org/articles/-/blogs/audio-quality-of-sbc-xq-bluetooth-audio-codec
> >>>>>>>> 
> >>>>>>>>>> Is there any bluez API for it?
> >>>>>>>>>> 
> >>>> 
> >>>> There quite a few assumption here that are not really how it is
> >>>> implemented in BlueZ:
> >>>> 
> >>>> 1. The L2CAP MTU is not based on the ACL link (should be relatively
> >>>> easy to change)
> >>>> 2. L2CAP MTU is not required to be symmetric.
> >>>> 3. Since the ACL link is shared for all channels we shouldn't really
> >>>> assume all throughput will be available
> >>>> 4. PA flow control is not just filling up packets and sending them
> >>>> when they are full to maximize speed, instead it send packets when
> >>>> necessary to maintain a constant speed so the MTU may not be fully
> >>>> used, in fact trying to maximize the MTU may result in higher latency
> >>>> since packets would be sent less frequently.
> >>>> 
> >>>> With this in mind I think the only thing we should look into is to
> >>>> adjust the default L2CAP MTU to match the underline ACL Link, so it
> >>>> maximizes throughput, the remote side may choose a different MTU which
> >>>> will have to follow though.
> >>> 
> >>> Hi Luiz! The main problem is not MTU size, as I wrote I cannot use it
> >>> normally for distinguish for usage of SBC XQ or not. Instead of MTU I
> >>> rather need to know if device supports EDR 2 or EDR 3.
> >> 
> >> I was trying to implement this on the kernel to match the MTU size of
> >> L2CAP with ACL but the packet type current in use by the connection is
> >> not exposed in the connection complete, or at least I couldn't any
> >> reference to it, we could possibly expose the packet types via socket
> >> option as well but changing it at runtime is probably not a good idea.
> > 
> > Hello, when I run btmon, I see following information very early before
> > creating A2DP connection:
> > 
> > HCI Event: Read Remote Supported Features (0x0b) plen 11
> >        Status: Success (0x00)
> >        Handle: 35
> >        Features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x59 0x87
> >          ...
> >          Enhanced Data Rate ACL 2 Mbps mode
> >          Enhanced Data Rate ACL 3 Mbps mode
> > 
> > I do not need to change MTU size, I would just like to know EDR features
> > capabilities. Cannot be those information exported somehow from kernel?
> > I guess that kernel should have these information if it can send it to
> > btmon.
> 
> so I have not seen a single device that only supports one of these two modes. They all support both and if possible you want to use 3 Mpbs anyway since that safes power.

Hi! But there are devices which support none of the two modes?

Anyway, could be these "features" exported as dbus property from bluez?

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

  reply index

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-11  8:27 Pali Rohár
2019-10-11 18:15 ` Gix, Brian
2019-10-11 18:35   ` Pali Rohár
2019-10-11 19:00     ` Gix, Brian
2019-10-11 19:05       ` Gix, Brian
2019-10-11 20:04         ` Pali Rohár
2019-10-12  7:23           ` Luiz Augusto von Dentz
2019-10-13  7:36             ` Pali Rohár
2019-10-13  8:45               ` Luiz Augusto von Dentz
2019-10-13  9:39                 ` Pali Rohár
2019-10-13  9:49                   ` Luiz Augusto von Dentz
2019-10-16 19:06                   ` Marcel Holtmann
2019-10-16 19:13                     ` Pali Rohár [this message]
2019-10-19 19:47                       ` Marcel Holtmann
2019-10-16 19:05           ` Marcel Holtmann

Reply instructions:

You may reply publically 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=20191016191343.clby7pmkdq3q2i7s@pali \
    --to=pali.rohar@gmail.com \
    --cc=brian.gix@intel.com \
    --cc=iam@valdikss.org.ru \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    --cc=marcel@holtmann.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

Linux-Bluetooth Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-bluetooth/0 linux-bluetooth/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-bluetooth linux-bluetooth/ https://lore.kernel.org/linux-bluetooth \
		linux-bluetooth@vger.kernel.org
	public-inbox-index linux-bluetooth

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-bluetooth


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git