-- ---------- Forwarded message ---------- Date: Sat, 6 Jan 2018 06:09:44 From: Sam Hartman <hartmans@xxxxxxxxxx> To: debian-accessibility at lists.debian.org Cc: pulseaudio at packages.debian.org Subject: Orca, Speech-dispatcher and power management Resent-Date: Sat, 6 Jan 2018 11:17:27 +0000 (UTC) Resent-From: debian-accessibility at lists.debian.org I'd appreciate being copied on replies. hi. A while ago I was looking at the power usage of our GUI screen reader stack. I came back to that project recently. I'm running stock stretch with Orca. I'm running pulseaudio and speech-dispatcher both as user processes. I was initially suspicious of the power used by the accessibility stack because speech-dispatcher is very heavy-handed in how it interacts with Pulse. On my system, it starts up sd_generic, sd_espeak_ng and sd_dummy. Each of these opens an audio stream with Pulse for the entire lifetime of the process. It seemed excessive to have that many processes running when all I want is Espeak. Another red (or at least bright yellow) flag is that the sound card can never auto suspend. That seemed concerning. Past experiments with the Jesse pulseaudio and speech-dispatcher suggested that the power usage was quite significant. I wrote a local patch that closed the sd_espeak pulse stream after seven seconds of inactivity. I did not get any significant clicking from such a patch. On Jesse that seemed to get me significantly better battery life. Certainly the powertop output was more promising. Battery usage was down as well as wakeups/second. On Stretch, things seem to be better without a patch. Several streams are still opened. Pulse still never auto-suspends the audio card. I sshed into the machine remotely and compared power usage when I ran pacmd suspend 1 (force suspend of the audio card) against what I got with the audio card running. Things seem to be significantly better than what I remember from Jessie. The estimated power draw from powertop can be as low as about 3.6W with pulse enabled and 3.2W with it suspended. It looks like it takes an hour of battery life or so to have pulse running with streams present and no actual sound being sent to these streams. It also looks like speech-dispatcher may have tried to improve things. It looks like sd_espeak_ng has a better concept of a stopped stream. That said, there are a couple of concerning factors. With Pulse streams present, pulse is responsible for about 230 additional powertop wakeups per second. It ends up being the top CPU utilization, although I think it stays down under 1ms/second. Clearly, this gets lost in the noise if the system is active. If you're actually interacting with GUI applications, the power used by the GUI, Orca, and AT-SPI (Orca and AT-SPI are surprisingly greedy) dwarfs the power used by Pulse and speech-dispatcher. However, what I'm worried about is idle power usage. There are a lot of times where my laptop will be sitting on the table idle for 15 minutes while I'm talking. The lower power usage at idle goes, the longer it will last under work loads I care a lot about. I'd like to figure out whether: * Will limiting the number of streams speech-dispatcher opens have any significant improvement. Are there actual costs to having the sd_generic and sd_dummy streams open even when they are unneeded? * Would it be worth the complexity to close the speech dispatcher streams after a period of inactivity? Has anyone else looked at stuff like this? Would anyone be interested in working with me on accessibility power usage? Thanks for your consideration, --Sam
