Hi folks, I'd like to bring this one up again, since we are currently in the sub-optimal position of forcing ~100 ms latency on USB devices. The original thread is here --
http://mailman.alsa-project.org/pipermail/alsa-devel/2013-December/069666.ht...
While we sort this out, though, is there an upper bound on the USB transfer size (that we could then use a rewind safety margin)? We might be able to use this as a workaround till this can be fixed properly.
Hello Arun,
thanks for bringing up the issue again. However, I think that the "~100
ms latency on batch cards" problem can and should also be solved from the other end, independently from the USB special case. Namely, I think that the default buffer and period sizes that PulseAudio selects are way too conservative. The power-saving argument was used in the past as a justification, and I am calling for a reevaluation. Here is why.
- Android's AudioFlinger uses 2 periods, 5 ms each. It is a mobile OS,
and the developers think it is good enough.
- I have measured the battery life time of my SandyBridge-based laptop
and found that, with pure ALSA on the hw:0 device, a similar low-latency setup loses less than 5% of the battery life (935 seconds were lost out of 25742). With PulseAudio, the difference is worse, but let's treat this as a missed optimization in PulseAudio.
http://www.intel.com/content/www/us/en/chipsets/high-definition-audio-energy...
Do your hda controller support EEaudio Mechanism ?