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@xxxxxxx> 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) {
>
>
