All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Oliphant <oliphant@nostatic.org>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org
Subject: Re: Support for NUX MG-300 USB interface
Date: Tue, 19 Jan 2021 09:40:04 -0800	[thread overview]
Message-ID: <CAHXb3bfUv7QzvgOmtV3LxJXaY=Uk+pKhWZmU0M+YkgB0kNrXmA@mail.gmail.com> (raw)
In-Reply-To: <s5hczy1guto.wl-tiwai@suse.de>

Your mixer.c patch does get rid of the RANGE errors. No change to behavior,
though.

I'd already tried setting "implicit_fb=1" even though I didn't expect it to
work, since there is a separate feedback endpoint. I just tried it again -
it doesn't seem to hurt anything, but it doesn't help either.

Capture seems to be working perfectly with the clock patch - I'm not sure
why I was initially getting noisy input.

I checked "/proc/asound/card*/pcm*/sub*/status" during playback, and the
pointer seems to be moving forward as it should. All indications are that
the system thinks playback is working fine.

One interesting piece of information - alsamixer shows two stereo outputs
("pcm" and "pcm1"). Not sure why there are two - maybe output is going to
the wrong one?

Here is the output from "/proc/asound/AUDIO/usbmixer":

USB Mixer: usb_id=0x1fc98260, ctrlif=0, ctlerr=0
Card: NUX NUX MG-300 AUDIO at usb-0000:00:1a.7-1.3, high speed
  Unit: 10
    Control: name="PCM Playback Volume", index=1
    Info: id=10, control=2, cmask=0x0, channels=1, type="S16"
    Volume: min=-16384, max=0, dBmin=-6400, dBmax=0
  Unit: 10
    Control: name="PCM Playback Volume", index=0
    Info: id=10, control=2, cmask=0x3, channels=2, type="S16"
    Volume: min=-16384, max=0, dBmin=-6400, dBmax=0
  Unit: 10
    Control: name="PCM Playback Switch", index=1
    Info: id=10, control=1, cmask=0x0, channels=1, type="INV_BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 10
    Control: name="PCM Playback Switch", index=0
    Info: id=10, control=1, cmask=0x3, channels=2, type="INV_BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 41
    Control: name="Clock Source 41 Validity", index=0
    Info: id=41, control=2, cmask=0x0, channels=1, type="BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0

Mike

On Tue, Jan 19, 2021 at 1:05 AM Takashi Iwai <tiwai@suse.de> wrote:

> On Tue, 19 Jan 2021 01:26:51 +0100,
> Mike Oliphant wrote:
> >
> > Unfortunately, the "uac_clock_selector_set_val()" call does not seem to
> > change anything.
>
> OK,
>
> > >From doing some more testing, I think that the references to clock id
> "40"
> > are ok - it has "40" stored in fmt->clock, but when it uses it,
> > "__uac_clock_find_source()" gets called and it resolved to the actual
> clock
> > source - "41".
> >
> > Not sure about the "No valid sample rate available for 1:1, assuming a
> > firmware bug" error, but I suspect it is spurious.
> > "check_valid_altsetting_v2v3()" is failing for some reason, but it is
> > ignoring the error.
>
> Yes, that's the part where verifying the altsetting for the given
> rate.  The UAC2 device must return the valid altsetting bit mask for
> the current rate in the request, but your device didn't seem returning
> it.  The code is there for devices like MOTU that have multiple
> altsets where each one has one sample rate exclusively.
>
> > Playback is completely silent, but the system seems to think it is
> working.
> > No apparent errors, and a play operation seems to take the correct amount
> > of time. Just no audio.
>
> Check the status in /proc/asound/card*/pcm*/sub*/status.  If the
> pointer moves forward and the position is expected, at least the data
> feed is done, and the problem must be something else.
>
> What about the capture?  Do you get also only silence?
>
> > Maybe it is a mixer issue? mixer.c is putting out "RANGE setting not yet
> > supported" errors on startup.
>
> That's probably no problem, I guess it comes from the code trying to
> get the resolution.  The patch below may paper over it.
>
> > Here is a sample of dmesg output for a playback session:
> >
> > [ 4748.260975] usb 1-1.3: Open EP 0x1, iface=1:1, idx=0
> > [ 4748.260983] usb 1-1.3:   channels=2, rate=48000, format=S32_LE,
> > period_bytes=48000, periods=4, implicit_fb=0
> > [ 4748.260988] usb 1-1.3: Open EP 0x81, iface=1:1, idx=1
> > [ 4748.260992] usb 1-1.3:   channels=2, rate=48000, format=S32_LE,
> > period_bytes=48000, periods=4, implicit_fb=0
> > [ 4748.260996] usb 1-1.3: Setting usb interface 1:0 for EP 0x1
> > [ 4748.261320] usb 1-1.3: 1:1 Set sample rate 48000, clock 40
> > [ 4748.261873] usb 1-1.3: Setting params for data EP 0x1, pipe 0x9d00
> > [ 4748.261890] usb 1-1.3: Set up 12 URBS, ret=0
> > [ 4748.261897] usb 1-1.3: Setting usb interface 1:1 for EP 0x1
> > [ 4748.262097] usb 1-1.3: Setting params for sync EP 0x81, pipe 0x9d80
> > [ 4748.262105] usb 1-1.3: Set up 4 URBS, ret=0
> > [ 4748.262147] usb 1-1.3: Starting data EP 0x1 (running 0)
> > [ 4748.262180] usb 1-1.3: 12 URBs submitted for EP 0x1
> > [ 4748.262183] usb 1-1.3: Starting sync EP 0x81 (running 0)
> > [ 4748.262193] usb 1-1.3: 4 URBs submitted for EP 0x81
> > [ 4748.262311] usb 1-1.3: 1:1 Start Playback PCM
> > [ 4762.887812] usb 1-1.3: Stopping sync EP 0x81 (running 1)
> > [ 4762.887836] usb 1-1.3: Stopping data EP 0x1 (running 1)
> > [ 4762.887849] usb 1-1.3: 1:1 Stop Playback PCM
> > [ 4762.902542] usb 1-1.3: Closing EP 0x1 (count 1)
> > [ 4762.902549] usb 1-1.3: Setting usb interface 1:0 for EP 0x1
> > [ 4762.902915] usb 1-1.3: EP 0x1 closed
> > [ 4762.902928] usb 1-1.3: Closing EP 0x81 (count 1)
> > [ 4762.902935] usb 1-1.3: Setting usb interface 1:0 for EP 0x81
> > [ 4762.903179] usb 1-1.3: EP 0x81 closed
>
> The flow looks good judging from this log, at least.
>
> The device is configured with the dedicated sync endpoint, but it's
> not with the implicit feedback mode.  It's interesting whether the
> device behaves differently if you load snd-usb-audio module with
> implicit_fb=1 boot option.  I don't expect it working better, but
> anyway...
>
>
> Takashi
>
> --- a/sound/usb/mixer.c
> +++ b/sound/usb/mixer.c
> @@ -1238,7 +1238,7 @@ static int get_min_max_with_quirks(struct
> usb_mixer_elem_info *cval,
>                                   (cval->control << 8) | minchn,
>                                   &cval->res) < 0) {
>                         cval->res = 1;
> -               } else {
> +               } else if (cval->head.mixer->protocol == UAC_VERSION_1) {
>                         int last_valid_res = cval->res;
>
>                         while (cval->res > 1) {
>
>

  reply	other threads:[~2021-01-19 18:36 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-17 18:56 Support for NUX MG-300 USB interface Mike Oliphant
2021-01-18  7:43 ` Takashi Iwai
2021-01-18 16:33   ` Mike Oliphant
2021-01-18 17:54     ` Mike Oliphant
2021-01-18 19:19       ` Takashi Iwai
2021-01-18 21:15         ` Mike Oliphant
2021-01-18 21:59           ` Takashi Iwai
2021-01-19  0:26             ` Mike Oliphant
2021-01-19  9:05               ` Takashi Iwai
2021-01-19 17:40                 ` Mike Oliphant [this message]
2021-01-20 14:33                   ` Takashi Iwai
2021-01-20 21:17                     ` Mike Oliphant
2021-01-20 21:38                       ` Takashi Iwai
2021-01-20 21:47                         ` Mike Oliphant
2021-01-21 19:04                           ` Mike Oliphant
2021-01-21 20:18                             ` Mike Oliphant

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='CAHXb3bfUv7QzvgOmtV3LxJXaY=Uk+pKhWZmU0M+YkgB0kNrXmA@mail.gmail.com' \
    --to=oliphant@nostatic.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=tiwai@suse.de \
    /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.