[pulseaudio-discuss] Orca, Speech-dispatcher and power management (fwd)

[Jude DaShiell]

-- 


---------- Forwarded message ----------
Date: Sat, 6 Jan 2018 06:09:44
From: Sam Hartman <hartmans at debian.org>
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