Hi,
John Keeping <john@xxxxxxxxxxxx> writes:
> On Thu, 16 Jan 2020 16:39:50 +0100
> Pavel Hofman <pavel.hofman@xxxxxxxxxxx> wrote:
>
>> > I've taken a look at this and the patch below fixes it in my simple
>> > testing. But note that this doesn't adjust the PCM's min_period_bytes
>> > which will be necessary if you want to minimize latency with an adjusted
>> > high-speed bInterval setting.
>> >
>>
>> Please can I ask you to submit your patch? IMO your perhaps slightly
>> suboptimal solution is much better than the current broken version.
>
> Yes, the patch is definitely an improvement. I thought it would be
> picked up from the earlier mail, but I think Patchwork requires the
> subject to match, so I'm including it again here.
>
> Are you able to provide a Tested-by for this change?
>
> -- >8 --
> Prior to commit eb9fecb9e69b ("usb: gadget: f_uac2: split out audio
> core") the maximum packet size was calculated only from the high-speed
> descriptor but now we use the largest of the full-speed and high-speed
> descriptors.
>
> This is correct, but the full-speed value is likely to be higher than
> that for high-speed and this leads to submitting requests for OUT
> transfers (received by the gadget) which are larger than the endpoint's
> maximum packet size. These are rightly rejected by the gadget core.
>
> config_ep_by_speed() already sets up the correct maximum packet size for
> the enumerated speed in the usb_ep structure, so we can simply use this
> instead of the overall value that has been used to allocate buffers for
> requests.
>
> Note that the minimum period for ALSA is still set from the largest
> value, and this is unavoidable because it's possible to open the audio
> device before the gadget has been enumerated.
>
> Signed-off-by: John Keeping <john@xxxxxxxxxxxx>
Acked-by: Felipe Balbi <balbi@xxxxxxxxxx>
--
balbi
Attachment:
signature.asc
Description: PGP signature
