Clock sync problem?

[Alexander Tsoy]

В Пн, 08/06/2020 в 15:35 +0200, Takashi Iwai пишет:
> On Mon, 08 Jun 2020 10:32:24 +0200,
> Thomas Ebeling wrote:
> > 
> > On 08.06.20 09:19, Takashi Iwai wrote:
> > > On Sun, 07 Jun 2020 15:39:59 +0200,
> > > Laurence Tratt wrote:
> > > > Hello,
> > > > 
> > > > I've found an interesting issue with an SSL2+ audio interface
> > > > -- it plays and
> > > > records fine (and, for the money, the sound quality is
> > > > excellent!), but
> > > > recording slowly but surely drifts over time. For example, if I
> > > > record a
> > > > click track in Audacity (or Ardour), play it through the
> > > > interface and record
> > > > it, and then line up the start of the recorded click track with
> > > > the original,
> > > > the two tracks will be around 5ms out of alignment after 30s.
> > > > Interestingly,
> > > > this problem does not happen with OpenBSD, where the two tracks
> > > > line up
> > > > precisely.
> > > > 
> > > The recent change in USB-audio might help for a case like yours.
> > > Try my sound git tree (for-linus branch) or Linus' tree.  The
> > > former
> > > should be pullable onto 5.7 kernel cleanly.
> > 
> > Since I recently had clock drift issues with Audient devices, I'm
> > intrigued by this. @Takashi Can you quickly elaborate, what you
> > think,
> > Laurance's issue might be and what has changed in that tree that
> > might
> > help him fix it? Is there some general issue with the current
> > (stable)
> > sound/usb implementation?
> 
> The frame size calculation in USB-audio driver wasn't accurate enough
> because of the computation in Q16.16 format.  It works OK for async
> mode, but for others, it can accumulate rounding errors.  The recent
> change corrected it for a more precise way.

I believe that SSL and Audient devices operates in async mode. Would be
nice to see "lsusb -v" output for them.