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