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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

bjb






[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux