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

[Jude DaShiell]

-- 


---------- Forwarded message ----------
Date: Sat, 6 Jan 2018 07:45:30
From: Samuel Thibault <sthibault at debian.org>
To: Sam Hartman <hartmans at debian.org>
Cc: debian-accessibility at lists.debian.org, pulseaudio at packages.debian.org
Subject: Re: Orca, Speech-dispatcher and power management
Resent-Date: Sat,  6 Jan 2018 12:45:50 +0000 (UTC)
Resent-From: debian-accessibility at lists.debian.org

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.

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

It's like screen saving: one is used to have to wait a bit for the
screen to wake up after having left the system idle for some time.

> I don't know if dormant streams have mixing overhead or impact the
> volume algorithms being used.

I don't think it's really measurable :)

>    >> * Would it be worth the complexity to close the speech dispatcher
>    >> streams after a period of inactivity?
>
>     Samuel> That could be useful indeed. I suggest reporting a feature
>     Samuel> request on the github speechd repository, so people can
>     Samuel> contribute code to implement it (Debian by itself should not
>     Samuel> integrate such a patch without it being upstream).
>
> So, I'm happy to implement if it's going to make a significant
> difference.

Well, I can believe the difference that you have measured, so to me it
makes sense.

Samuel