On Tue, Jun 30, 2020 at 12:54:07PM -0400, Sasha Levin wrote: > On Tue, Jun 30, 2020 at 01:49:50PM +0300, Alexander Tsoy wrote: > > В Пн, 29/06/2020 в 11:37 -0400, Sasha Levin пишет: > > > From: Alexander Tsoy <alexander@xxxxxxx> > > > > > > [ Upstream commit f0bd62b64016508938df9babe47f65c2c727d25c ] > > > > > > For computation of the the next frame size current value of fs/fps > > > and > > > accumulated fractional parts of fs/fps are used, where values are > > > stored > > > in Q16.16 format. This is quite natural for computing frame size for > > > asynchronous endpoints driven by explicit feedback, since in this > > > case > > > fs/fps is a value provided by the feedback endpoint and it's already > > > in > > > the Q format. If an error is accumulated over time, the device can > > > adjust fs/fps value to prevent buffer overruns/underruns. > > > > > > But for synchronous endpoints the accuracy provided by these > > > computations > > > is not enough. Due to accumulated error the driver periodically > > > produces > > > frames with incorrect size (+/- 1 audio sample). > > > > > > This patch fixes this issue by implementing a different algorithm for > > > frame size computation. It is based on accumulating of the remainders > > > from division fs/fps and it doesn't accumulate errors over time. This > > > new method is enabled for synchronous and adaptive playback > > > endpoints. > > > > > > Signed-off-by: Alexander Tsoy <alexander@xxxxxxx> > > > Link: > > > https://lore.kernel.org/r/20200424022449.14972-1-alexander@xxxxxxx > > > Signed-off-by: Takashi Iwai <tiwai@xxxxxxx> > > > Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx> > > > --- > > > sound/usb/card.h | 4 ++++ > > > sound/usb/endpoint.c | 43 ++++++++++++++++++++++++++++++++++++++-- > > > --- > > > sound/usb/endpoint.h | 1 + > > > sound/usb/pcm.c | 2 ++ > > > 4 files changed, 45 insertions(+), 5 deletions(-) > > > > Please drop this patch from the queue for now (and for 4.4 as well). It > > introduced a regression for some devices. The fix is available, but not > > accepted yet. > > I've dropped it from the older branches, but note that it's already in > newer released stable kernels. Should it be reverted or should we wait > for the fix? I was going to wait for the fix.
