Re: Behringer WING usb audio - cyclic xruns dependent on periods/buffers

[Takashi Iwai <tiwai@suse.de>]

On Thu, 03 Dec 2020 21:06:24 +0100,
Ben Bell wrote:
> 
> On Sat, Nov 28, 2020 at 09:36:00AM +0000, Ben Bell wrote:
> > > In general you should avoid 44.1kHz if you want a small period size
> > > for a realtime process on USB-audio.  With 44.1kHz, the packet size
> > > can't be fixed in integer, and the ISO transfer requires variable
> > > packet sizes.  OTOH, ALSA API requires the fixed period size, hence
> > > it'll lead to inconsistencies occasionally.
> 
> So changing to 48kHz had no appreciable effect, but I'm working at that
> rate for now to eliminate the 44.1kHz weirdness from investigations.
> Using a USB2 card, also had no effect. Testing with a different USB audio
> interface (albeit a simple stereo one) didn't exhibit the behaviour, even
> when I took buffer sizes right down.
> 
> I'm not sure where to go to get more information or where's the best place
> to ask for help. I'm happy to do the leg work, but I don't know enough
> about the kernel, alsa or USB to figure it out without some help.
> 
> Current question: what is the delay in /proc/asound/card1/pcm0c/sub0/status
> actually measuring? I'm assuming it's measured in samples? I've written
> something to scrape the stats out in a tight loop and report.
> 
> What I see is a cycle where the delay rises and then a chunk equal to the
> frames per period (or sometimes, earlier on fpp-48) is removed. That feels
> like chunks being read out of a buffer. All fine.
> 
> After a while though, the maximum delay we reach with each cycle is creeping
> up. It increases by one every few cycles (usually two or three, or three or
> four -- always oscillating between two values) but of it's still only being
> emptied by a full period's worth of samples each cycle. So the overall effect
> is the delay creeps up and up until it hits the buffer size and then we get
> an xrun.
> 
> Like I said in the initial email, it feels like some sort of clock drift
> problem, where we're managing very slowly to collect more samples than
> we're reading -- to the tune of about 1 extra every few cycles -- and
> nothing on the consumer side is ever managing to compensate for that.
> I'm not even sure how that sort of drift would be possible though. Seems
> surprising.
> 
> Does any of this sound suspicious, or for that matter completely normal?
> Any suggestions where should I be looking next?

At least you can try the latest patch set destined for 5.11, which
should improve the cases for the implicit feedback.

The patches are either in linux-next tree or the
topic/usb-audio-refactoring branch of my sound.git tree.
It's based on 5.10-rc, so should be cleanly mergeable to the latest
Linus tree.


Takashi