[alsa-devel] [PATCH] ALSA: usb-audio: set the interface format after resume on Dell WD19

Hui Wang hui.wang at canonical.com
Thu Dec 19 07:23:41 CET 2019


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 at 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 at 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/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].

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.

Thanks,

Hui.


> Kai-Heng
>
>>
>> Takashi
>> _______________________________________________
>> Alsa-devel mailing list
>> Alsa-devel at alsa-project.org
>> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel


More information about the Alsa-devel mailing list