>>>>> "Felipe" == Felipe Sateler <fsate...@gmail.com> writes:
Felipe> On Jan 6, 2018 09:36, "Sam Hartman" <hartm...@debian.org> wrote:
>>>>>> "Samuel" == Samuel Thibault <sthiba...@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.
Sam> So, this is more of a Pulse question. We know even
Sam> dormant streams are sufficient to keep the audio card from
Sam> suspending. I don't know if dormant streams have mixing
Sam> overhead or impact the volume algorithms being used.
Felipe> This depends on what dormant means, I think. Dormant
Felipe> audio can mean: 1. Steady stream of 0s.
Felipe> 2.
Felipe> Pausing (corking
Felipe> in pulse-speak) the stream. 3. Closing the stream entirely.
I think we're dealing with option 4: not actually writing enough and
allowing the stream to drain.
The stream flags on the streams in question are generally 'drained' not
'corked'. I don't know if corked displays as a status in
list-sink-inputs, but if it does, we're not seeing that.
Auto suspend is enabled and these streams are sufficient to block
autosuspend. I get that by comparing the output of list-cards and
list-sinks when the streams are not present (and the card does
autosuspend) to the output when it is present.
Samuel>I just meant that the presence of the modules themselves is not a
problem.
Sam> If there's a benefit in suspending the card that we lose even with
Sam> dormant streams, then that's a cost.
Samuel>Speech dispatcher controls the audio output, it does not matter how
Samuel>many modules are there, speech dispatcher can still shut down the
Samuel>corresponding audio streams.
So, I think you're aware of this, but just to make sure the broader we
are all on the same page:
Speech-dispatcher the program (the speech dispatcher server in the
source tree) doesn't do anything with audio.
The modules are not modules in the libtool or dll sense, and certainly
anyone coming from Pulseaudio would get the wrong impression thinking
about them.
Instead each speech-dispatcher module is its own process, forked and
execed from a different binary by the speech dispatcher server.
Speech dispatcher provides a set of audio libraries that get linked in
(statically?) to each module, including a pulse library.
Because of the structure of that module it's mostly assumed that the
module rather than the audio library will control when the stream is
open or not.
It looked tricky in the Jessie version of speech-dispatcher to change
that and for example close the Pulse stream without closing the
speech-dispatcher abstraction.
This is mostly true because speech-dispatcher uses blocking threads
rather than an event loop. The blocking happens in the module, *not*
the audio library.
So it's hard for the audio library to notice that nothing is going on.
The Stretch version seems better in this regard. It looks like there's
an interface for a module to communicate to an audio library that a
stream has stopped.
It might be relatively easy to use that abstraction to cork or entirely
close a Pulse stream.
It was definitely easy to modify the espeak module in the Jessie speech
dispatcher to entirely close its speech dispatcher audio abstraction
after an idle timeout.
It looks like doing something similar to the stretch Espeak-ng module
would be possible.
--Sam
