Hi Alan, On Sat, Sep 15, 2012 at 11:03:39AM -0400, Alan Stern wrote: > On Sat, 15 Sep 2012, Matthijs Kooijman wrote: > > > Hi folks, > > > > I've spent some time this week trying to debug frequent hiccups in my > > audio playback, on my USB sound card. The short version is that it seems > > the 24 ms worth of queued URBs is not enough, since the urb complete handler > > is frequently called too late and sometimes more than 16ms (plus 8ms in > > the urb that completed is 24ms) too late, causing a hiccup in the sound. > > ... > > > - Or are the delays in the urb completion handler / interrupt by > > definition a bug in (some other part of) the code? In that case, I > > might be able to dig in deeper to find and fix the cause of the > > delays, if someone can offer some suggestions about where to look for > > the problem. > > Delays that long should be looked into. They may or may not be caused > by bugs, but the chance that they are means that they deserve > investigation. The bugs don't have to like in the USB stack; they > could be anywhere in the kernel. Tracking them down is not necessarily > easy to do. Ok. I'll be happy to try your suggestions, but for some reason I don't understand, this issue has completely disappeared for me, from one day to the next. I'm still having some stuttering when using pulseaudio's equalizer module, but this seems to be a seperate issue (no "delay" messages involved). Regardless of this, I'm still wondering if increasing the queue size would make sense, especially from a interrupts per second / power usage point of view. However, increasing MAX_QUEUE is not enough here: It only causes more urbs of 8 ms/urb to get queue (up to 8 currently, for a max buffer of 64 ms). However, since there is an interrupt for every urb, this doesn't help to reduce the number of interrupts. What does help, is increasing nrpacks. I tried bumping MAX_PACKS to 400 and passing nrpacks=400 on module load, which makes the interrupt rate drop from 120/s to 3/s (since there are now always two urbs queued with 400ms worth of data each, instead of three urbs with 8ms of data each). I'm not sure if there's a direct power usage gain, since paplay and pulseaudio seemed to still cause a considerable number of wakeups, but in theory, it should at least help. I guess that just raising nrpacks by itself is not enough to make this work, since that creates a very big buffer that alsa clients can't touch, causing a big minimum latency. I'm not completely sure how this stuff works, but I guess there should be some way for an alsa client to rewind the stream, causing one or more urbs to canceled and resubmitted? Gr. Matthijs
Attachment:
signature.asc
Description: Digital signature
