Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp1889573ybj; Wed, 6 May 2020 07:11:56 -0700 (PDT) X-Google-Smtp-Source: APiQypJpVTRhPFUlTpPnS+rb89oGVsE/1lnNgigeiKHHl2AASfyv/95P3L5g3W6BPK8zVvfw377u X-Received: by 2002:a05:6402:1297:: with SMTP id w23mr6927519edv.151.1588774316163; Wed, 06 May 2020 07:11:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588774316; cv=none; d=google.com; s=arc-20160816; b=nejf7G6Fb58hjUxiSynyFhEAk/Xqmt0YrikCDF18MUwDhnMnCXqhqaUDojgQKTVqhj peXk1ardOqQZAhumlbPW6/gT8lnfmD3U8gaqlPe2A37oMM478X8T5XrhMLmrHxJJFTBn XXR0opNsIxo922UZffmnwMjczEd2PPWPpkCPj05hH+MAX2TbJaERETQhN80bcabDtEkN /03AlhZfgD2c4IGMQLLUiwfcw8LjDaaQ9IvtfIN5YUAdtiJULP0QStkK4gUgO6xPqjun HCCW4CZK3n9yww4Gvb7Q4vCSoMrObri8euCKZY5/Ahlf3Jzc8uD127gyNkrIFGG0+4dO d4eQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=fbwZ4r0pD7kFrVz9VwcR9OzSHWMeBGF3+0hoo6t/ztE=; b=pkaW2S6WCDlzweQVnF5+sw68wCI0hw+QbCWCpMZBJwXmdD+ZkLqzJ2mJS+nlLclV32 ATggi8CVe/lIqVLnoUeFvMbpaj5+rWm8nVg6lNIL5lv8/LcUCUh5UudDwjVefL+XQ6Ua WRe9Sg19OzmktH+yf+4bOGg6GV0SPLA558lhruc6yLyhxroNB62lmxSjjkvzHp0v7kCI zFGiul/FTVkPxZ/u2MLofJww3x3GrU8kjcqc2o5aYLHQikt113ZN0KHlgAVHkHoqSXqM pJDNZidhCH12KCsUB9f3O0+XFJiTScRvffKmgckCnpBpvBj2vKQqKiX03j4l6+wMSQ/c bJWA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=FHNG3ZpO; spf=pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d63si1115554edd.226.2020.05.06.07.11.29; Wed, 06 May 2020 07:11:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=FHNG3ZpO; spf=pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728717AbgEFOKy (ORCPT + 99 others); Wed, 6 May 2020 10:10:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47208 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728248AbgEFOKy (ORCPT ); Wed, 6 May 2020 10:10:54 -0400 Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A600DC061A0F for ; Wed, 6 May 2020 07:10:53 -0700 (PDT) Received: by mail-lj1-x241.google.com with SMTP id b2so2523630ljp.4 for ; Wed, 06 May 2020 07:10:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fbwZ4r0pD7kFrVz9VwcR9OzSHWMeBGF3+0hoo6t/ztE=; b=FHNG3ZpOz27M3QbsjBJwzo2oUKAleunIUJE+lbDJh4EawFpXm5GJqhwes847/NLLWt wqUgE7LtvQlXesxfSExb5nBB3/Tq1eJaGxmWWCmELSm62dPIds4VY5tzktSWVgR9waaJ 1IIHTWZHL+4+QH6nB+45sEi+58VbGTGLgOIBEduffFYK1O7JIQtFDdHQTAsxxJUQB7M1 AQTNWAUwyJhYhyZ5V3k4EtR01YPWrxJ4INzfX/m2l63uoERL0UflSabxkQEd/iOj2NkV vKouIXjz5I1/5L5XwzxqEMgey0cXJVYHkGeI1T7n6mix3CMKMGN1w4IO6gmb4dLdGJ1K tsTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fbwZ4r0pD7kFrVz9VwcR9OzSHWMeBGF3+0hoo6t/ztE=; b=iGSaCpKl+g+SED0jyKJB8ww0xwQHDhW+an1fPxZTWQPyKHn+WCbZvvyHOK8ApL0Z6k 5rmIU3RpYyQAd/GuQDDSbvXbAGmgJ3gLAdWWNe7xXkW1b9SMwt4shqql0QCWyb+VPLpU Yo+wVBtuYilr9XBEwSEApJztCwK7rndaSm1kEupid34ca9ulJ8IrFG/hsLgLzI7A4Kmq nYmikFdzrZS8WknmR+mN/yHbWuppittfk+s4xBFiQcOlN+tN5B3jHqiCxWxMQtBIbkaq P5btCwFjv6BwMxepc1LVJCkKsS0SnCh9uug3JyEF8F3zq3YoQXvYg3hJGwOv8coS/Ouu kItQ== X-Gm-Message-State: AGi0PuaqmHoS+t/hDx3cI7s2MnzUPcBkQf0gC4OgwYjkeYvsvAisu8xx f7WtS8vmutW4omc4RKrsW1FyygL3WvUKvGOLbQQEgA== X-Received: by 2002:a2e:9c9a:: with SMTP id x26mr5234870lji.44.1588774251644; Wed, 06 May 2020 07:10:51 -0700 (PDT) MIME-Version: 1.0 References: <20200403153331.101846-1-alainm@chromium.org> In-Reply-To: From: Alain Michaud Date: Wed, 6 May 2020 10:10:38 -0400 Message-ID: Subject: Re: [Bluez PATCH v1 1/2] doc:adding a WidebandSpeechEnabled Api To: Luiz Augusto von Dentz Cc: Marcel Holtmann , Alain Michaud , BlueZ Content-Type: text/plain; charset="UTF-8" Sender: linux-bluetooth-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org Hi Luiz, On Tue, May 5, 2020 at 7:48 PM Luiz Augusto von Dentz wrote: > > Hi Marcel and Alain, > > On Tue, May 5, 2020 at 8:47 AM Alain Michaud wrote: > > > > Friendly ping on this series. > > > > > > On Tue, May 5, 2020 at 11:46 AM Alain Michaud wrote: > > > > > > Friendly ping on this series. > > > > > > On Fri, Apr 17, 2020 at 5:03 PM Alain Michaud wrote: > > >> > > >> On Fri, Apr 17, 2020 at 4:58 PM Luiz Augusto von Dentz > > >> wrote: > > >> > > > >> > Hi Alain, > > >> > > > >> > On Fri, Apr 17, 2020 at 11:22 AM Alain Michaud wrote: > > >> > > > > >> > > On Fri, Apr 17, 2020 at 2:16 PM Luiz Augusto von Dentz > > >> > > wrote: > > >> > > > > > >> > > > Hi Alain, > > >> > > > > > >> > > > On Thu, Apr 16, 2020 at 5:34 PM Alain Michaud wrote: > > >> > > > > > > >> > > > > HI Luiz, > > >> > > > > > > >> > > > > On Thu, Apr 16, 2020 at 8:29 PM Luiz Augusto von Dentz wrote: > > >> > > > >> > > >> > > > >> Hi Alain, > > >> > > > >> > > >> > > > >> On Thu, Apr 16, 2020 at 1:32 PM Alain Michaud wrote: > > >> > > > >> > > > >> > > > >> > Friendly ping on this series. > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > On Fri, Apr 3, 2020 at 11:33 AM Alain Michaud wrote: > > >> > > > >> > > > > >> > > > >> > > This change adds an adapter Api to report the controller's > > >> > > > >> > > widebandspeech enabled state. > > >> > > > >> > > >> > > > >> I wonder if this shouldn't be queried over SCO socket, or simple fail > > >> > > > >> with BT_VOICE when using BT_VOICE_TRANSPARENT which is how what is > > >> > > > >> normally used when using mSBC. > > >> > > > > > > >> > > > > I think there is value in both. > > >> > > > > > >> > > > Can you expand on that? I think this might generate confusion if the > > >> > > > property indicates support for it but HFP implementation don't support > > >> > > > it, since the later is usually implemented as a external profile so we > > >> > > > don't have the features it may support, or perhaps the intention here > > >> > > > is to actually indicate when it is in use? > > >> > > > > >> > > This is a signal that the adapter supports it and has everything > > >> > > enabled to support it. Driver indicated it supports it and erroneous > > >> > > data reporting was enabled. The profile has it's own state which may > > >> > > indicate if msbc will be used, but this will be on a per connection > > >> > > basis and is independent from this adapter property. > > >> > > > > >> > > The value in this property is to support diagnostic UX about > > >> > > controller capabilities/state and also allow profiles that are > > >> > > implemented outside of bluetoothd to see which codec it can attempt to > > >> > > negotiate with the device. > > >> > > > >> > For diagnosic I think we would be better off with some dedicated > > >> > interface to query this, as for the later the information we are > > >> > giving does not actually tell anything about the codec support, which > > >> > was part of my original argument that for the likes of HFP and other > > >> > profiles using it it might not be enough and they still need to use > > >> > BT_VOICE in order to enable the use of custom codecs, if you take > > >> > ofono for example it does implement support for wideband speech > > >> > already and it would completely disregard this property which can give > > >> > the false impression that wideband speech cannot be activated when in > > >> > fact it can, it just don't have erroneous data reporting enable, so > > >> > perhaps we should indicate the actual adapter feature (e.g. > > >> > ErrnoneousDataReporting) not the profile feature here, so the profile > > >> > implementation can check weather this would disable use of wideband > > >> > speech or not, futhermore we should probably report the errors back to > > >> > the SCO socket or is that just for diagnostic and cannot be used to > > >> > adjust the streaming? > > >> > > >> My original patch actually had this MGMT feature called erroneous data > > >> reporting and Marcel argued against it. If you both agree, then I'm > > >> happy to rename all of this to erroneous data reporting. We'd still > > >> need some way for the driver support to be messaged some other way > > >> though. see: > > >> > > >> if (id->driver_info & BTUSB_WIDEBAND_SPEECH) > > >> set_bit(HCI_QUIRK_WIDEBAND_SPEECH_SUPPORTED, &hdev->quirks); > > So this will get a little bit confusing if we don't have a HFP > implementation that actually does implement the profile parts to > enable wideband speech so I wonder if we should rename it to the > underline feature it enables, that said this sort of feature is > probably easier to be queried over the socket itself rather than over > D-Bus so it can be used in conjunction with the likes of BT_VOICE, > also regarding the erroneous data should that be also enabled by the > HFP profile, because depending on the platform it may not support > wideband speech so enabling erroneous data automatically may result in > artifacs, specially in cases where the codecs don't have error > correction or data loss concealment to handle data with possible error > and lost data respectively, btw we don't seem to be parsing the > SCO/ESCO flags and even if we do this properly we need to find a way > to notify them over the socket so things like plc works properly. This indeed makes sense, but we'll need to decide how erroneous data reporting gets enabled. The SCO socket is a per connection scope thing while erroneous data reporting is a controller level thing. > > > >> > > >> > > >> > > > > > >> > > > > > >> > > > >> > > >> > > > >> > > >> > > > >> > > --- > > >> > > > >> > > > > >> > > > >> > > doc/adapter-api.txt | 8 ++++++++ > > >> > > > >> > > 1 file changed, 8 insertions(+) > > >> > > > >> > > > > >> > > > >> > > diff --git a/doc/adapter-api.txt b/doc/adapter-api.txt > > >> > > > >> > > index acae032d9..d8865e795 100644 > > >> > > > >> > > --- a/doc/adapter-api.txt > > >> > > > >> > > +++ b/doc/adapter-api.txt > > >> > > > >> > > @@ -326,3 +326,11 @@ Properties string Address [readonly] > > >> > > > >> > > > > >> > > > >> > > Local Device ID information in modalias format > > >> > > > >> > > used by the kernel and udev. > > >> > > > >> > > + > > >> > > > >> > > + boolean WidebandSpeechEnabled [readonly] > > >> > > > >> > > + > > >> > > > >> > > + Returns true if the adapter's wideband speech feature is > > >> > > > >> > > + supported and enabled. > > >> > > > >> > > >> > > > >> There seems to be some extra empty lines here. > > >> > > > > > > >> > > > > ACK, will fix. > > >> > > > >> > > >> > > > >> > > >> > > > >> > > + > > >> > > > >> > > + > > >> > > > >> > > + > > >> > > > >> > > -- > > >> > > > >> > > 2.26.0.292.g33ef6b2f38-goog > > >> > > > >> > > > > >> > > > >> > > >> > > > >> > > >> > > > >> > > >> > > > >> -- > > >> > > > >> Luiz Augusto von Dentz > > >> > > > > > >> > > > > > >> > > > > > >> > > > -- > > >> > > > Luiz Augusto von Dentz > > >> > > > >> > > > >> > > > >> > -- > > >> > Luiz Augusto von Dentz > > > > -- > Luiz Augusto von Dentz