On Mon, 24 Sep 2012, Matthijs Kooijman wrote: > 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. That wasn't your goal. According $SUBJECT, your goal is to prevent hiccups in the audio stream. > 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? This is a matter for the ALSA and sound driver people, not for me. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
