12.06.2015 17:32, Arun Raghavan wrote:
On 12 June 2015 at 17:59, Arun Raghavan arun@accosted.net wrote:
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.
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.
Let me make my viewpoint more explicit: from now on, I will reject CPU usage measurements as an evidence for "real power-saving problems", unless a correlation factor between them and the battery life has been also measured on the same device. Direct measurements of the battery life in reproducible conditions are of course welcome.
Raw data for the experiment (2) with pure ALSA are attached. The first column is the time since boot, in seconds, and the second column is the remaining energy in the battery, in microwatt-hours, as reported in the energy_now sysfs attribute. report-1428125745.txt is with --period-size=44100 --buffer-size=88200, report-1428161181.txt is with --buffer-size=440 --period-size=220, the test file is a 44100 Hz, S16, stereo wav file.
To guarantee the reproducibility of this experiment, the entire system (Gentoo stage3 plus PulseAudio plus laptop-mode-tools) has been put in the initramfs, together with a script that turns off the backlight and then repeatedly plays a wav file from the same initramfs through aplay. The wi-fi card has been turned off with a hardware toggle. So everything (including the SSD) during the test is unused, except CPU, memory, and the onboard sound card. That's why the test exhibits unrealistically long battery life.
If my result gets confirmed on a laptop that is not a former flagman from Sony, then I would argue for the following:
1. Change of the default buffer and period sizes for batch cards in PulseAudio to values that represent, on modern hardware, say, 2.5% of battery life reduction as compared to very large periods.
2. Limiting of the sleep time in the timer-based scheduling logic to a similar value. If this ends up below 30 ms, then we can simplify PulseAudio by removing all traces of the rewind logic.