[Bug 218992] New: headset

[Bug 218992] New: headset

[bugzilla-daemon]

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: drivers_usb@kernel-bugs.kernel.org
          Reporter: quic_ugoswami@quicinc.com
        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:

-- 
You may reply to this email to add a comment.

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

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

[bugzilla-daemon]

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

Udipto (quic_ugoswami@quicinc.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|headset                     |Usb Type-C headset TX is
                   |                            |noise

--- Comment #1 from Udipto (quic_ugoswami@quicinc.com) ---
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

-- 
You may reply to this email to add a comment.

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

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

[bugzilla-daemon]

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

--- Comment #2 from Udipto (quic_ugoswami@quicinc.com) ---
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.

-- 
You may reply to this email to add a comment.

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

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

[bugzilla-daemon]

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

--- Comment #3 from Udipto (quic_ugoswami@quicinc.com) ---
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.

-- 
You may reply to this email to add a comment.

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