On Thu, 01 Sep 2022 17:25:41 +0200, Sean Anderson wrote:
On 8/28/22 3:49 AM, Takashi Iwai wrote:
On Fri, 26 Aug 2022 20:57:53 +0200, Sean Anderson wrote:
On 8/26/22 12:36 PM, Takashi Iwai wrote:
On Fri, 26 Aug 2022 18:22:24 +0200, Sean Anderson wrote:
Hi all,
I have a "FiiO DigiHug USB Audio" sound card (1852:7022) [3]. I have had no problems with the audio, but I did notice a large number of message like
retire_capture_urb: 4992 callbacks suppressed
in my dmesg [1]. This is caused by the "Corrected urb data len." warning.
What exact values are shown there?
Unfortunately, as detailed below, I was unable to turn off ratelimiting.
The problem is that your hardware (likely a buggy firmware) returns the unaligned size of bytes as the data. Maybe it's worth to replace dev_warn_ratelimited() there with dev_warn() and take all warnings once. Then we can see what kind of values are delivered from the hardware.
I'll have an attempt at that next week
The patch adding this warning [2] makes it seem like this warning should be an uncommon occurance. However, based on the number of suppressed callbacks, this seems to be happening at a rate of around 500 Hz.
Is this buggy hardware? Or is this a bug in the driver? Does there need to be a quirk? Or perhaps the warning above should be a debug instead?
There is no quirk for that. As long as the device works with that workaround (except for messages), we can simply add a quirk to not warn but always apply the workaround silently for such devices.
OK. I wasn't sure what the correct resolution would be.
Actually I was wrong: the existing quirk QUIRK_FLAG_ALIGN_TRANSFER should cover that.
Could you try to pass quirk_flags=0x04 for the corresponding card slot (the option takes an array) to snd-usb-audio module? Alternatively, try to pass quirk_alias=18557022:0e510408 to snd-usb-audio?
I tried both options, but neither worked.
I have no further idea. You should try the latest kernel without modification before checking further.
And, looking at the code again, it's really strange that you get those messages. Actually the transfer size *is* aligned to the audio frames as default *unless* QUIRK_FLAG_ALIGN_TRANSFER is passed. And the check is done rather the audio sample size alignment -- which must fit within the audio frame alignment.
So, QUIRK_FLAG_ALIGN_TRANSFER is already set for your device by some reason incorrectly, or the code is doing wrong on your kernel. We need to check what values are shown there actually, then check whether the problem happens with the latest vanilla kernel.
Takashi