> On Dec 19, 2019, at 4:35 PM, Takashi Iwai <tiwai@xxxxxxx> wrote: > > On Thu, 19 Dec 2019 07:37:07 +0100, > Kai Heng Feng wrote: >> >> >> >>> On Dec 19, 2019, at 2:23 PM, Hui Wang <hui.wang@xxxxxxxxxxxxx> 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@xxxxxxx> 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@xxxxxxxxxxxxx> >>>>> 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/f7b3537bbf9a6916ee3fd72a82025519b4c346f5 >>>> [2] https://gitlab.freedesktop.org/pulseaudio/pulseaudio/commit/734a00c849815a45697970d593068c301a04ebbb >>> >>> 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. > > Not really, the world is not only with PA. > > The standard alsa-lib function snd_pcm_recover() just calls > snd_pcm_prepare() when snd_pcm_resume() fails. That is, the stream is > re-prepared and re-triggered without closing for the device that has > no SNDRV_PCM_INFO_RESUME flag. Understood, so that's indeed a kernel bug. Kai-Heng > > > Takashi > >>> >>> 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@xxxxxxxxxxxxxxxx >>>>> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
