From: Marcel Holtmann <marcel@holtmann.org>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: "Pali Rohár" <pali@kernel.org>,
"Joakim Tjernlund" <Joakim.Tjernlund@infinera.com>,
"linux-bluetooth@vger.kernel.org"
<linux-bluetooth@vger.kernel.org>
Subject: Re: Default to HW mSBC on capable controllers ?
Date: Mon, 28 Dec 2020 13:42:26 +0100 [thread overview]
Message-ID: <A9EA687A-E9BB-44B7-82EA-DE8F83D142D4@holtmann.org> (raw)
In-Reply-To: <CABBYNZK1kRCvhXnoMbskTYdoFUCOTSAdfUVqv3yftfp_G3NxFA@mail.gmail.com>
Hi Luiz,
>>>>> There seems to be quite a few USB controllers gaining the BTUSB_WIDEBAND_SPEECH which I guess means HW mSBC
>>>>
>>>> No, it does not mean mSBC.
>>>>
>>>
>>> I forgot, if BTUSB_WIDEBAND_SPEECH does not mean capable of HW mSBC, what does it mean?
>>
>> BTUSB_WIDEBAND_SPEECH flag is just for usb bluetooth adapters. Not for
>> UART or SDIO bluetooth adapters.
>>
>> It is a hint set for some bluetooth adapters which are on kernel
>> whitelist that wideband speech support is possible for them.
>
> Actually it is meant indicate to application that BT_PKT_STATUS can be
> used which enables the implementation of PLC (Packet Loss
> Concealment), Ive been advocating to change it or just remove it
> entirely and move it to be queried with BT_PKT_STATUS.
after we fixed the bug with the SCO packet flags, we might not even need this anymore at all and just enable the error reporting unconditionally.
On a side note, I insisted on calling this WIDEBAND_SPEECH option since we should be hiding details behind a single flag and not spread multiple flags for things that need to be combined into one logical feature anyway.
Regards
Marcel
prev parent reply other threads:[~2020-12-28 12:43 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-18 13:32 Default to HW mSBC on capable controllers ? Joakim Tjernlund
2020-12-18 19:43 ` Luiz Augusto von Dentz
2020-12-20 17:09 ` Joakim Tjernlund
2020-12-21 21:14 ` Pali Rohár
2020-12-22 1:54 ` Luiz Augusto von Dentz
2020-12-22 9:21 ` Pali Rohár
2020-12-22 9:36 ` Jamie Mccrae
2020-12-22 9:48 ` Pali Rohár
2020-12-22 10:05 ` Marcel Holtmann
2020-12-22 10:19 ` Pali Rohár
2020-12-22 11:04 ` Marcel Holtmann
2020-12-22 11:46 ` Pali Rohár
2020-12-22 12:20 ` Marcel Holtmann
2020-12-22 13:17 ` Pali Rohár
2020-12-22 21:11 ` Marcel Holtmann
2020-12-22 21:13 ` Pali Rohár
2020-12-31 10:09 ` Pasi Kärkkäinen
2021-01-13 14:46 ` Pali Rohár
2020-12-21 21:07 ` Pali Rohár
2020-12-22 11:40 ` Pasi Kärkkäinen
2020-12-22 11:49 ` Pali Rohár
2020-12-22 13:20 ` Pali Rohár
2020-12-23 15:41 ` Joakim Tjernlund
2020-12-23 15:56 ` Pali Rohár
2020-12-23 21:58 ` Luiz Augusto von Dentz
2020-12-28 12:42 ` Marcel Holtmann [this message]
Reply instructions:
You may reply publicly 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=A9EA687A-E9BB-44B7-82EA-DE8F83D142D4@holtmann.org \
--to=marcel@holtmann.org \
--cc=Joakim.Tjernlund@infinera.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=pali@kernel.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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.