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

Jude DaShiell jdashiel at panix.com
Sat Jan 6 15:40:25 UTC 2018


---------- Forwarded message ----------
Date: Sat, 6 Jan 2018 09:26:39
From: Sam Hartman <hartmans at debian.org>
To: debian-accessibility at lists.debian.org
Cc: pulseaudio at packages.debian.org
Subject: Re: Orca, Speech-dispatcher and power management
Resent-Date: Sat,  6 Jan 2018 14:27:02 +0000 (UTC)
Resent-From: debian-accessibility at lists.debian.org

>>>>> "Samuel" == Samuel Thibault <sthibault at debian.org> writes:

     Samuel> Sam Hartman, on sam. 06 janv. 2018 07:36:25 -0500, wrote:
     >> >>>>> "Samuel" == Samuel Thibault <sthibault at debian.org> writes:
     Samuel> Hello,
     Samuel> Sam Hartman, on sam. 06 janv. 2018 06:09:44 -0500, wrote:
     >> >> * 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?
     Samuel> I don't think there is: they remain dormant.
     >> So, this is more of a Pulse question.  We know even dormant
     >> streams are sufficient to keep the audio card from suspending.

     Samuel> Yes, because the drivers want to be ready to emit sound very
     Samuel> quickly.  But to me it makes sense that e.g. after one
     Samuel> minute or such speech dispatcher shuts down its stream to
     Samuel> let the card get idle, at the expense of a little extra
     Samuel> latency to reopen it again, but that should be hardly
     Samuel> noticeable: it's only during work that one notices latency.

That makes sense to me, but is different than your earlier answer of it
shouldn't matter because they are dormant.
If there's a benefit in suspending the card that we lose even with
dormant streams, then that's a cost.
I cannot imagine having sd_dummy be low latency be worth any cost at
Similarly for non-active synthesizers: high latency to switch synths
seems entirely reasonable.

It looks like the pulse code in speech-dispatcher may make this easier
than it was with the old code.
I'll see what I can pull together and see what happens.
I'll try and open the feature request soon, but throwing together an
initial implementation may take a couple of months just because it's
competing with a lot of things.


More information about the pulseaudio-discuss mailing list