All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Marco Giunta <giun7a@gmail.com>
Cc: alsa-devel@alsa-project.org
Subject: Re: [PATCH] Fix mic sound on Jieli webcam
Date: Thu, 17 Dec 2020 13:17:45 +0100	[thread overview]
Message-ID: <s5h8s9wlj86.wl-tiwai@suse.de> (raw)
In-Reply-To: <CAE5BBpTbyjkd--Nfcqpv01wYyScEgXJSQETYhWyUH9-qPKYw+g@mail.gmail.com>

On Thu, 17 Dec 2020 12:49:53 +0100,
Marco Giunta wrote:
> 
> Hi,
> thank you for your reply. As I told you, I'm not the guy who wrote the
> patch, but I try to continue his work.
> 
> > What's the original datainterval value for those altsettings?
> Where I can read the original datainterval value ? Is it an USB
> property (so I can search in udev) ? Or can I debug in some way the
> snd_usb_audio module load to get the values ?

bInterval in the descriptor should show the value.
At best, give the output of lsusb -v for the device.


thanks,

Takashi

> 
> Thanks,
>   Marco
> 
> 
> On Thu, Dec 17, 2020 at 10:50 AM Takashi Iwai <tiwai@suse.de> wrote:
> >
> > On Tue, 15 Dec 2020 10:44:45 +0100,
> > Marco Giunta wrote:
> > >
> > > Hi,
> > > recently I've bought a usb webcam with integrated mic:
> > >
> > >   Jieli Technology USB PHY 2.0 (1224:2a25)
> > >
> > > The video part works well, but the mic sound is speedups, "like
> > > minions" (cit.). When I connect the camera, these are the dmesg
> > > messages:
> > >
> > > kernel: usb 1-8: current rate 0 is different from the runtime rate 8000
> > > kernel: usb 1-8: current rate 0 is different from the runtime rate 16000
> > > kernel: usb 1-8: current rate 0 is different from the runtime rate 44100
> > > kernel: usb 1-8: current rate 0 is different from the runtime rate 48000
> > > kernel: usb 1-8: Warning! Unlikely big volume range (=4096), cval->res
> > > is probably wrong.
> > > kernel: usb 1-8: [3] FU [Mic Capture Volume] ch = 1, val = 0/4096/1
> > > kernel: usbcore: registered new interface driver snd-usb-audio
> > >
> > > and after a while, dmesg log is filled, every 5 seconds, with:
> > >
> > > kernel: retire_capture_urb: 84 callbacks suppressed
> > > kernel: retire_capture_urb: 1714 callbacks suppressed
> > >
> > > A guy reports on ArchLinux bug website the same problem
> > > (https://bugs.archlinux.org/task/68141?opened=12995&status%5B0%5D=)
> > > and provides a patch to fix the sound issue. I've applied the patch on
> > > kernel 5.9.13 (Fedora 33 x86_64) and now the mic works, no more
> > > minions voice effect. Now dmesg messages are only:
> > >
> > > kernel: usb 1-8: Warning! Unlikely big volume range (=4096), cval->res
> > > is probably wrong.
> > > kernel: usb 1-8: [3] FU [Mic Capture Volume] ch = 1, val = 0/4096/1
> > > kernel: usbcore: registered new interface driver snd-usb-audio
> > >
> > > the retire_capture_urb messages are gone.
> > >
> > > All credits for the patch go to him but I don't know how to contact
> > > that guy nor I don't know if he has already contacted you, so my
> > > question is if you could review his patch and finally apply upstream.
> > >
> > > If you need other information or you need a tester, I'm here.
> >
> > Thanks for the patch.  The still remaining warnings are about the
> > mixer, and your patch doesn't touch about it.  You may apply the
> > similar change in volume_control_quirks() like other webcams.
> >
> > And now about the patch:
> >
> > > --- a/sound/usb/format.c    2020-10-01 18:36:35.000000000 +0300
> > > +++ b/sound/usb/format.c    2020-10-04 02:10:21.678685952 +0300
> > > @@ -217,6 +217,21 @@
> > >                  (chip->usb_id == USB_ID(0x041e, 0x4064) ||
> > >                   chip->usb_id == USB_ID(0x041e, 0x4068)))
> > >                  rate = 8000;
> > > +
> > > +            // hack for "Jieli Technology USB PHY 2.0" webcam
> > > +            if (chip->usb_id == USB_ID(0x1224, 0x2a25)) {
> > > +                switch (rate) {
> > > +                case 8000:
> > > +                    fp->datainterval += 4;
> > > +                    break;
> > > +                case 16000:
> > > +                    fp->datainterval += 3;
> > > +                    break;
> > > +                default:
> > > +                    fp->datainterval += 1;
> > > +                    break;
> > > +                }
> > > +            }
> >
> > Modifying datainterval at this point doesn't look intuitive.
> > What's the original datainterval value for those altsettings?
> > The value is retrieved in snd_usb_parse_datainterval() in helper.c,
> > and if any, the correction there would be more sensible.
> >
> >
> > >              fp->rate_table[fp->nr_rates] = rate;
> > >              if (!fp->rate_min || rate < fp->rate_min)
> > > --- a/sound/usb/endpoint.c    2020-10-01 18:36:35.000000000 +0300
> > > +++ b/sound/usb/endpoint.c    2020-10-04 02:09:09.471978982 +0300
> > > @@ -882,6 +882,8 @@
> > >      if (snd_usb_get_speed(ep->chip->dev) != USB_SPEED_FULL) {
> > >          packs_per_ms = 8 >> ep->datainterval;
> > >          max_packs_per_urb = MAX_PACKS_HS;
> > > +        if (!packs_per_ms)
> > > +            packs_per_ms = 1;
> >
> > This rather indicates that the datainterval is somehow wrong.
> >
> > >      } else {
> > >          packs_per_ms = 1;
> > >          max_packs_per_urb = MAX_PACKS;
> > > --- a/sound/usb/quirks.c    2020-10-01 18:36:35.000000000 +0300
> > > +++ b/sound/usb/quirks.c    2020-10-04 02:14:04.532196519 +0300
> > > @@ -1516,6 +1516,7 @@
> > >      case USB_ID(0x1901, 0x0191): /* GE B850V3 CP2114 audio interface */
> > >      case USB_ID(0x21b4, 0x0081): /* AudioQuest DragonFly */
> > >      case USB_ID(0x2912, 0x30c8): /* Audioengine D1 */
> > > +    case USB_ID(0x1224, 0x2a25): /* Jieli Technology USB PHY 2.0 */
> > >          return true;
> > >      }
> >
> > This looks fine.
> >
> >
> > thanks,
> >
> > Takashi
> 

  reply	other threads:[~2020-12-17 12:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-15  9:44 [PATCH] Fix mic sound on Jieli webcam Marco Giunta
2020-12-17  9:50 ` Takashi Iwai
2020-12-17 11:49   ` Marco Giunta
2020-12-17 12:17     ` Takashi Iwai [this message]
2020-12-17 13:24       ` Marco Giunta
2020-12-17 14:12         ` Takashi Iwai
2020-12-18  9:26           ` Marco Giunta
2020-12-18 15:31             ` Takashi Iwai
2020-12-19  9:48               ` Marco Giunta

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=s5h8s9wlj86.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=giun7a@gmail.com \
    /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.