[pulseaudio-discuss] Orca, Speech-dispatcher and power management (fwd)
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> 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