Skip to contentSkip to conversation

New: headset

Bug 218992 [email protected] 1 participant 4 messages Jun 27, 2024 USB

lore
Share & tools
lore
#0 lore raw

https://bugzilla.kernel.org/show_bug.cgi?id=218992

            Bug ID: 218992
           Summary: headset
           Product: Drivers
           Version: 2.5
          Hardware: ARM
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: USB
          Assignee: [email protected]
          Reporter: [email protected]
        Regression: No

I'm encountering an issue where the USB audio is transmitted in noise instead of valid data. This was found on SM8650.

Steps to reproduce are as follows:
1. Start Connect USB type-c headset.
2. Start the Karaoke with USB-headset
Result:

Signature · 4 lines
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.
#1 lore raw

[Bug 218992] Usb Type-C headset TX is noise

https://bugzilla.kernel.org/show_bug.cgi?id=218992

Udipto ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------

            Summary|headset                     |Usb Type-C headset TX is
                   |                            |noise

--- Comment #1 from Udipto ([email protected]) ---
The issue only happened one specific USB-headphone that it supports 44.1k to capture.

The log:

<6>[316.777381] [pid:    22] usb 1-1: new high-speed USB device number 2 using
xhci-hcd
<6>[316.918353] [pid:    22] usb 1-1: New USB device found, idVendor=0424,
idProduct=2422, bcdDevice= 0.a0
<6>[316.918382] [pid:    22] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
<6>[318.229277] [pid:  1921] usb 1-1.1: new high-speed USB device number 3
using xhci-hcd
<6>[318.326969] [pid:  1921] usb 1-1.1: New USB device found, idVendor=0499,
idProduct=170d, bcdDevice= 1.10
<6>[318.327014] [pid:  1921] usb 1-1.1: New USB device strings: Mfr=1,
Product=2, SerialNumber=0
<6>[318.327048] [pid:  1921] usb 1-1.1: Product: AG06/AG03
<6>[318.327079] [pid:  1921] usb 1-1.1: Manufacturer: Yamaha Corporation

05-13 19:43:47.220 root 8 8 E usb 1-1.1: Mismatched sample rate 48000
vs 44100 for EP 0x82

Is coming up on dmesg.

This is the audio card info of the headset:
USB audio card info:
proc/asound/card1 # cat stream0
Yamaha Corporation AG06/AG03 at usb-xhci-hcd.2.auto-1.1, high speed : USB Audio

Playback:
Status: Stop
Interface 1
Altset 1
Format: S32_LE
Channels: 2
Endpoint: 0x01 (1 OUT) (ASYNC)
Rates: 44100, 48000, 88200, 96000, 176400, 192000 Data packet interval: 125 us
Bits: 24
Channel map: FL FR
Sync Endpoint: 0x81 (1 IN)
Sync EP Interface: 1
Sync EP Altset: 1
Implicit Feedback Mode: No

Capture:
Status: Stop
Interface 2
Altset 1
Format: S32_LE
Channels: 2
Endpoint: 0x82 (2 IN) (ASYNC)
Rates: 44100, 48000, 88200, 96000, 176400, 192000 Data packet interval: 125 us
Bits: 24
Channel map: FL FR

Signature · 4 lines
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.
#2 lore raw

[Bug 218992] Usb Type-C headset TX is noise

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=218992

--- Comment #2 from Udipto ([email protected]) --- One more info:

Looking at endpoint.c code I think the function snd_usb_endpoint_open extracts the ep->clock_ref using clock_ref_find(chip, fp->clock) and this remains same for all endpoints available.

In the issue case when the error mismatch sample rate comes up, looks like the ep->clock_ref->opened is 2, and it will not decrease to 0 when we close EP 0x82 because EP 0x1 is opened. Also the clock_ref->rate will not go to 0 when close EP 0x82.

Signature · 4 lines
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.
#3 lore raw

[Bug 218992] Usb Type-C headset TX is noise

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=218992

--- Comment #3 from Udipto ([email protected]) --- One more info:

Looking at endpoint.c code I think the function snd_usb_endpoint_open extracts the ep->clock_ref using clock_ref_find(chip, fp->clock) and this remains same for all endpoints available.

In the issue case when the error mismatch sample rate comes up, looks like the ep->clock_ref->opened is 2, and it will not decrease to 0 when we close EP 0x82 because EP 0x1 is opened. Also the clock_ref->rate will not go to 0 when close EP 0x82.

Signature · 4 lines
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.