| Message ID | 20210514031901.2276-1-hildawu@realtek.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] Bluetooth: btusb: Add support USB ALT 3 for WBS | expand |
This is automated email and please do not reply to this email! Dear submitter, Thank you for submitting the patches to the linux bluetooth mailing list. This is a CI test results with your patch series: PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=482217 ---Test result--- Test Summary: CheckPatch PASS 0.52 seconds GitLint PASS 0.10 seconds BuildKernel PASS 504.61 seconds TestRunner: Setup PASS 331.32 seconds TestRunner: l2cap-tester PASS 2.44 seconds TestRunner: bnep-tester PASS 1.85 seconds TestRunner: mgmt-tester PASS 27.49 seconds TestRunner: rfcomm-tester PASS 2.05 seconds TestRunner: sco-tester PASS 1.96 seconds TestRunner: smp-tester PASS 2.05 seconds TestRunner: userchan-tester PASS 1.87 seconds Details ############################## Test: CheckPatch - PASS - 0.52 seconds Run checkpatch.pl script with rule in .checkpatch.conf ############################## Test: GitLint - PASS - 0.10 seconds Run gitlint with rule in .gitlint ############################## Test: BuildKernel - PASS - 504.61 seconds Build Kernel with minimal configuration supports Bluetooth ############################## Test: TestRunner: Setup - PASS - 331.32 seconds Setup environment for running Test Runner ############################## Test: TestRunner: l2cap-tester - PASS - 2.44 seconds Run test-runner with l2cap-tester Total: 40, Passed: 40 (100.0%), Failed: 0, Not Run: 0 ############################## Test: TestRunner: bnep-tester - PASS - 1.85 seconds Run test-runner with bnep-tester Total: 1, Passed: 1 (100.0%), Failed: 0, Not Run: 0 ############################## Test: TestRunner: mgmt-tester - PASS - 27.49 seconds Run test-runner with mgmt-tester Total: 416, Passed: 403 (96.9%), Failed: 0, Not Run: 13 ############################## Test: TestRunner: rfcomm-tester - PASS - 2.05 seconds Run test-runner with rfcomm-tester Total: 9, Passed: 9 (100.0%), Failed: 0, Not Run: 0 ############################## Test: TestRunner: sco-tester - PASS - 1.96 seconds Run test-runner with sco-tester Total: 8, Passed: 8 (100.0%), Failed: 0, Not Run: 0 ############################## Test: TestRunner: smp-tester - PASS - 2.05 seconds Run test-runner with smp-tester Total: 8, Passed: 8 (100.0%), Failed: 0, Not Run: 0 ############################## Test: TestRunner: userchan-tester - PASS - 1.87 seconds Run test-runner with userchan-tester Total: 3, Passed: 3 (100.0%), Failed: 0, Not Run: 0 --- Regards, Linux Bluetooth
Hi Hilda, > Because mSBC frames do not need to be aligned to the SCO packet > boundary. Using USB ALT 3 let HCI payload >= 60 bytes, let mSBC > data satisfy 60 Bytes avoid payload unaligned situation and fixed > some headset no voise issue. > > USB Alt 3 supported also need HFP support transparent MTU in 72 Bytes. > > Signed-off-by: Hilda Wu <hildawu@realtek.com> > --- > Changes in v2: > - Updated signed off name. > - Adjusted coding style. > --- > --- > drivers/bluetooth/btusb.c | 7 +++++++ > 1 file changed, 7 insertions(+) patch has been applied to bluetooth-next tree. Regards Marcel
Hi, pe, 2021-05-14 kello 11:19 +0800, hildawu@realtek.com kirjoitti: > From: Hilda Wu <hildawu@realtek.com> > > Because mSBC frames do not need to be aligned to the SCO packet > boundary. Using USB ALT 3 let HCI payload >= 60 bytes, let mSBC > data satisfy 60 Bytes avoid payload unaligned situation and fixed > some headset no voise issue. > > USB Alt 3 supported also need HFP support transparent MTU in 72 > Bytes. > > Signed-off-by: Hilda Wu <hildawu@realtek.com> > --- > Changes in v2: > - Updated signed off name. > - Adjusted coding style. > --- This change seemed to break msbc audio on some non-realtek adapters I have. Tested Pipewire on BCM20702A1 (0b05:17cb), CSR8510A10 (0a12:0001) -> no sound output and input appears garbled. Reverting this patch makes it work again. Indeed these adapters report SCO mtu=64 which is less than 72. On the other hand, with RTL8761BU (0bda:8771) msbc audio works fine with this patch out of the box, indeed reading/writing 72 byte packets to/from the sco socket. ALT 3 on RTL8761BU does appear to address garbled audio with some headsets. Maybe the altsetting should be determined based on a quirk, the mtu requirement be checked, or something similar? AFAIK, userspace can't do anything to fix this. Best, Pauli Virtanen > --- > drivers/bluetooth/btusb.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c > index 6f253378e893..1e98f985740b 100644 > --- a/drivers/bluetooth/btusb.c > +++ b/drivers/bluetooth/btusb.c > @@ -1752,6 +1752,13 @@ static void btusb_work(struct work_struct > *work) > * which work with WBS at all. > */ > new_alts = btusb_find_altsetting(data, 6) ? 6 > : > 1; > + /* Because mSBC frames do not need to be > aligned to the > + * SCO packet boundary. If support the Alt 3, > use the > + * Alt 3 for HCI payload >= 60 Bytes let air > packet > + * data satisfy 60 bytes. > + */ > + if (new_alts == 1 && > btusb_find_altsetting(data, 3)) > + new_alts = 3; > } > > if (btusb_switch_alt_setting(hdev, new_alts) < 0)
On Sunday, July 11, 2021 8:33:57 AM PDT Pauli Virtanen wrote: > pe, 2021-05-14 kello 11:19 +0800, hildawu@realtek.com kirjoitti: > > Because mSBC frames do not need to be aligned to the SCO packet > > boundary. Using USB ALT 3 let HCI payload >= 60 bytes, let mSBC > > data satisfy 60 Bytes avoid payload unaligned situation and fixed > > some headset no voise issue. > > > > USB Alt 3 supported also need HFP support transparent MTU in 72 > > Bytes. > > This change seemed to break msbc audio on some non-realtek adapters I > have. Tested Pipewire on BCM20702A1 (0b05:17cb), CSR8510A10 (0a12:0001) > -> no sound output and input appears garbled. Reverting this patch > makes it work again. Indeed these adapters report SCO mtu=64 which is > less than 72. On the other hand, with RTL8761BU (0bda:8771) msbc audio > works fine with this patch out of the box, indeed reading/writing 72 > byte packets to/from the sco socket When I fixed WBS when previous patches from Intel and Realtek broke it for most adapters, I also tested alt 3. I also found it didn't work for many adapters. It is annoying that a chipset vendor can not be bothered to do the basic testing I am able to do by buying random bt adapters from amazon. Nor respond when their patches, once accepted, cause problems.
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index 6f253378e893..1e98f985740b 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -1752,6 +1752,13 @@ static void btusb_work(struct work_struct *work) * which work with WBS at all. */ new_alts = btusb_find_altsetting(data, 6) ? 6 : 1; + /* Because mSBC frames do not need to be aligned to the + * SCO packet boundary. If support the Alt 3, use the + * Alt 3 for HCI payload >= 60 Bytes let air packet + * data satisfy 60 bytes. + */ + if (new_alts == 1 && btusb_find_altsetting(data, 3)) + new_alts = 3; } if (btusb_switch_alt_setting(hdev, new_alts) < 0)