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
