[alsa-devel] PulseAudio and SNDRV_PCM_INFO_BATCH

[Raymond Yau]

>>> 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.html
>>
>>
>> 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.
>
> 1. Android's AudioFlinger uses 2 periods, 5 ms each. It is a mobile OS,
and the developers think it is good enough.
>
> 2. 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-efficient-audio-buffering.html

Do your hda controller support EEaudio Mechanism ?