ACK: [SRU][Xenial][Yakkety][PATCH 1/1] UBUNTU: SAUCE: (no-up) ALSA: usb-audio: Add quirk for sennheiser officerunner

Tim Gardner tim.gardner at canonical.com
Fri Sep 16 16:06:51 UTC 2016


On 09/16/2016 08:46 AM, Joseph Salisbury wrote:
> From: David Britton <davidpbritton at gmail.com>
> 
> BugLink: http://bugs.launchpad.net/bugs/1622763
> 
> This USB headset doesn't seem to support sample rate polling, similar to this issue:
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=95961
> 
> Every time something goes to interact with the device (playing a sound 
> file, opening the sound panel, opening web audio/video), a 10 second pause 
> is encountered, where dmesg prints out two messages:
> 
>   usb 2-1.2: 2:1: cannot get freq at ep 0x83
>   usb 2-1.2: 2:1: cannot get freq at ep 0x83
> 
> Once the sound is playing, everything is fine. These sample rate polls 
> don't seem to keep happening. After waiting for maybe 30 seconds after 
> sound is playing, future interactions will again trigger the pause.
> 
> This 10 second pause can introduce other subtle problems. For instance, 
> google hangouts will sometimes timeout waiting for the sound device to
> respond, and the browser tab will crash or not fully load as a result. The 
> sound panel often also will not display the device in the list of choices,
>  and you will have to close it out. Sometimes restart pulse audio to get it
>  to recognize the headset again.
> 
> Signed-off-by: Joseph Salisbury <joseph.salisbury at canonical.com>
> ---
>  sound/usb/quirks.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
> index db11ecf..6faf2f9 100644
> --- a/sound/usb/quirks.c
> +++ b/sound/usb/quirks.c
> @@ -1144,6 +1144,7 @@ bool snd_usb_get_sample_rate_quirk(struct snd_usb_audio *chip)
>  	case USB_ID(0x1de7, 0x0014): /* Phoenix Audio TMX320 */
>  	case USB_ID(0x1de7, 0x0114): /* Phoenix Audio MT202pcs */
>  	case USB_ID(0x21B4, 0x0081): /* AudioQuest DragonFly */
> +	case USB_ID(0x1395, 0x740a): /* Sennheiser Officerunner */
>  		return true;
>  	}
>  	return false;
> 

Low possibility for regression. You should get David's s-o-b in the
commit log before sending it upstream.

rtg
-- 
Tim Gardner tim.gardner at canonical.com




More information about the kernel-team mailing list