linux-kernel - Re: [alsa-devel] [PATCH 1/3 v1] ALSA: usb-audio: more tolerant packetsize

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Thu, 1 Dec 2016 13:15:39 +0100
From:   Clemens Ladisch <clemens@...isch.de>
To:     Jiada Wang <jiada_wang@...tor.com>
Cc:     alsa-devel@...a-project.org, tiwai@...e.com,
        linux-kernel@...r.kernel.org, Mark_Craske@...tor.com,
        apape@...adit-jv.com
Subject: Re: [alsa-devel] [PATCH 1/3 v1] ALSA: usb-audio: more tolerant
 packetsize

Jiada Wang wrote:
> On 11/30/2016 11:41 PM, Clemens Ladisch wrote:
>> Jiada Wang wrote:
>>> since commit 57e6dae1087bbaa6b33d3dd8a8e90b63888939a3 the expected packetsize is always limited to
>>> nominal + 25%. It was discovered, that some devices
>>
>> Which devices?
>
> It was a LG nexus

So it was the Android audio accessory mode.

>>> have a much higher jitter in used packetsizes than 25%
>>
>> How high?
>
> the nominal packet size was somewhere around 176bytes
> +25% would result in max expected packets to be ~220bytes
> We observed some packets exceeding this size (256byte)

256 bytes per USB frame would correspond to 64 kHz, instead of the
nominal 44.1 kHz.

The audio accessory sample format is fixed, and that mode is no longer
developed, so increasing the limit to +50% would be sufficient to work
around this problem.

I don't know if this is a bug in Google's generic AOA code, or if LG did
some changes; I have not heard any other report so far ...

Regards,
Clemens