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