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