From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9A35CCA9EAB for ; Sat, 19 Oct 2019 19:47:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 65E5F21D7C for ; Sat, 19 Oct 2019 19:47:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726130AbfJSTrl convert rfc822-to-8bit (ORCPT ); Sat, 19 Oct 2019 15:47:41 -0400 Received: from coyote.holtmann.net ([212.227.132.17]:44682 "EHLO mail.holtmann.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726118AbfJSTrl (ORCPT ); Sat, 19 Oct 2019 15:47:41 -0400 Received: from marcel-macbook.fritz.box (p4FEFC197.dip0.t-ipconnect.de [79.239.193.151]) by mail.holtmann.org (Postfix) with ESMTPSA id 02A30CED0E; Sat, 19 Oct 2019 21:56:38 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) Subject: Re: Determinate EDR speed From: Marcel Holtmann In-Reply-To: <20191016191343.clby7pmkdq3q2i7s@pali> Date: Sat, 19 Oct 2019 21:47:39 +0200 Cc: Luiz Augusto von Dentz , Brian Gix , "iam@valdikss.org.ru" , "linux-bluetooth@vger.kernel.org" Content-Transfer-Encoding: 8BIT Message-Id: References: <319f751481bbdb5aa012e5fa4daa1d95965b54c3.camel@intel.com> <20191011183502.ao45xlyfabpbadxo@pali> <64060b6a2bc9aee7b7eef0347ee3bafe3fddd18b.camel@intel.com> <20191011200420.hbrutdclfva2uqpv@pali> <20191013073603.6jnczqr4fk7lpyxq@pali> <20191013093947.cbqczgnt3uo3f5wi@pali> <20191016191343.clby7pmkdq3q2i7s@pali> To: =?utf-8?Q?Pali_Roh=C3=A1r?= X-Mailer: Apple Mail (2.3594.4.19) Sender: linux-bluetooth-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org 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? and these devices are super rare. Actually I think that HFP 1.7 ended up mandated EDR support. > Anyway, could be these "features" exported as dbus property from bluez? Not as easily as you think. We would have to do that via L2CAP socket if we wanted to do this cleanly and useful. Right now bluetoothd doesn’t know anything about the remote features. And the plain LMP features set is something that I wouldn’t expose anyway since the majority of the feature bits are really just for the LMP entities and not the host or the profiles. Regards Marcel