On Dec 19, 2019, at 2:23 PM, Hui Wang hui.wang@canonical.com wrote:
On 2019/12/19 下午12:55, Kai Heng Feng wrote:
Hi Hui and Takashi,
On Dec 19, 2019, at 3:06 AM, Takashi Iwai tiwai@suse.de wrote:
On Wed, 18 Dec 2019 14:26:50 +0100, Hui Wang wrote:
Recently we found the headset-mic on the Dell Dock WD19 doesn't work anymore after s3 (s2i or deep), this problem could be workarounded by closeing (pcm_close) the app and then reopening (pcm_open) the app, so this bug is not easy to be detected by users.
When problem happens, retire_capture_urb() could still be called periodically, but the size of captured data is always 0, it could be a firmware bug on the dock. Anyway I found after resuming, the snd_usb_pcm_prepare() will be called, and if we forcibly run set_format() to set the interface and its endpoint, the capture size will be normal again. This problem and workaound also apply to playback.
To fix it in the kernel, add a quirk to let set_format() run forcibly once after resume.
Signed-off-by: Hui Wang hui.wang@canonical.com
Thanks, the workaround looks reasonable. I applied it now with Cc to stable.
I am not entirely sure it’s a kernel bug. [1] [2] can also fix the issue.
Since USB audio doesn’t have SNDRV_PCM_INFO_RESUME capability, userspace shouldn’t try to use snd_pcm_resume(). Commit [1] uses snd_pcm_drop() to make the device leave suspended state and the device behaves correctly with the fix.
[1] https://gitlab.freedesktop.org/pulseaudio/pulseaudio/commit/f7b3537bbf9a6916... [2] https://gitlab.freedesktop.org/pulseaudio/pulseaudio/commit/734a00c849815a45...
Thanks for sharing the info, [1] could workaround this bug because it finally called pcm_close() and pcm_open(), [2] doesn't change the executing path in th PA, it is a cosmetic improvement for [1].
In [2], if PCM doesn't support hardware resume, like USB audio, it falls through to default and calls snd_pcm_drop() to let device leave suspended state. So it’s more than a cosmetic change.
I guess it is a firmware problem, and could be fixed in the kernel. Because I tested many other usb audio cards, they don't need workaroud of [1], they all could playback and capture after resuming, so this problem is specific to this hardware. And in theory a device should work same before and after suspend, it should not depend on userspace to close it and reopen it. After adding this fix, this usb audio card could work after resuming even on a system without PA. And this kernel patch doesn't have any conflict with [1]/[2] in the PA, they could work well together.
Yes the two approaches are orthogonal in some sense. However if the issue can be solved by following alsa-lib's documentation, I don't think it's a kernel bug.
Kai-Heng
Thanks,
Hui.
Kai-Heng
Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel