Linux-Bluetooth Archive on
 help / color / Atom feed
From: "Pali Rohár" <>
To: "Gix, Brian" <>
Cc: ValdikSS <>,
Subject: Re: Determinate EDR speed
Date: Fri, 11 Oct 2019 20:35:02 +0200
Message-ID: <20191011183502.ao45xlyfabpbadxo@pali> (raw)
In-Reply-To: <>

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


On Friday 11 October 2019 18:15:47 Gix, Brian wrote:
> Hi Pali,
> On Fri, 2019-10-11 at 10:27 +0200, Pali Rohár wrote:
> > Hello!
> > 
> > I would like to ask, how can userspace application which uses bluez DBus
> > API determinate EDR speed of remote bluetooth device?
> > 
> > Particularly, I'm interested in detection if bluetooth headset supports
> > EDR 2 Mbps or EDR 3 Mbps speed and based on this decide which SBC
> > parameters would be used for encoding audio via SBC codec.
> There are a variety of things that can affect real-time throughput, and I think even EDR 2 vs 3 might
> dynamically change to fit the current conditions.  If you have the ability to have fine control of the SBC
> parameters, I think the *best* way to adjust for throughput is to choose what sample rate and subands you
> want, and then squeeze or expand the bitpool to fit your throughput. (bitpool is something that can be
> dynamically adjusted, I believe, without re-negotiation).

I know about all SBC parameters, I'm implementing/improving SBC codec
support in pulseaudio, de-facto standard way how current Linux desktop
system can do playback via bluetooth/bluez.

I'm already using fixed SBC subbands and sample rate based on pulseaudio
source. And SBC bitpool is really the thing which I want to choose based
on EDR 2 vs 3 availability.

ValdikSS (CCed) created a nice calculator for SBC codec parameters and
via it you can easily calculate which bitpool values you want to use to
minimize wasted bytes in bluetooth frames. But to do it, you need to
know MTU resp. information if device supports EDR 2 or EDR 3.

> Howeverever, the real question is how to tell what the instantaneous realtime throughput is...  which is
> certainly affected by support for EDR2 vs EDR3, but is also affected by distance, RSSI, environmental RF, and
> what the other L2CAP channels on the connection are carrying (AVRCP for example).
> I don't think a simple boolean for EDR2 and/or EDR3, especially in user space, is going to give you the level
> of information you need.

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.

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

See these two articles for more details about SBC and its high quality:

> > 
> > Is there any bluez API for it?
> > 

Pali Rohár

[-- 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 [this message]
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

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191011183502.ao45xlyfabpbadxo@pali \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Bluetooth Archive on

Archives are clonable:
	git clone --mirror 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/ \
	public-inbox-index linux-bluetooth

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone