Linux-Bluetooth Archive on lore.kernel.org
 help / color / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: "Pali Rohár" <pali.rohar@gmail.com>
Cc: 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:05:15 +0200
Message-ID: <2DFEA001-74D0-45AE-BAAE-110E075D0E9E@holtmann.org> (raw)
In-Reply-To: <20191011200420.hbrutdclfva2uqpv@pali>

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.

actually the kernel doesn’t know either. We start with an allowed packet type mask and then the LC on each side will negotiate the current used packet types. These can change at any time. So if you want to know the current packet type, we would have to poll for it, but there is also no command that can do that.

The only thing that could be done is to limit the allowed packet types when creating the connection. However that again defeats the purpose since A2DP is not the only user of that ACL link.

What might be useful is to start using the flow specification and configure it on an ACL if an L2CAP socket for audio has been created.

Regards

Marcel


      parent 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
2019-10-19 19:47                       ` Marcel Holtmann
2019-10-16 19:05           ` Marcel Holtmann [this message]

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=2DFEA001-74D0-45AE-BAAE-110E075D0E9E@holtmann.org \
    --to=marcel@holtmann.org \
    --cc=brian.gix@intel.com \
    --cc=iam@valdikss.org.ru \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=pali.rohar@gmail.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

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