speech-dispatcher-dummy stream can not be monitored, stuck in PA_STREAM_CREATING state
Opened this issue · 2 comments
Steps to reproduce
Using Plasma Volume applet which has stream monitoring feature. The applet's VolumeMonitor object creates a pa_stream for monitoring peak volume levels of inputs and outputs. In case of "speech-dispatcher-dummy", the stream is stuck in PA_STREAM_CREATING state, and won't ever change states. We can not close a "CREATING" stream right away, and deferred closing via pa_stream_set_state_callback is useless because the state won't ever change. This causes a leak of one stream per switching to Applications tab in the applet.
Obtained behavior
Dummy stream is stuck, it can not be closed, and eventually causes a leak in Plasma.
Expected behavior
Definitely not this.
Behavior information
Configuration files are basically untouched/default Arch Linux configs. espeak-ng module actually plays some audio via its own stream (tested with spd-say command), and it also suffers the same issue, but stuck/leaked streams are removed once the module starts synthesizing some speech.
Distribution
Arch Linux
Version of Speech-dispatcher
speech-dispatcher: 0.11.5-1
espeak-ng: 1.51.1-2
pipewire: 1:1.0.0-2
pipewire-pulse: 1:1.0.0-2
pulseaudio-qt: 1.3-1
Additional information
Downstream bug report in Plasma (sort of, there seem to be multiple bugs behind it): https://bugs.kde.org/show_bug.cgi?id=477522
Closely related issue in pipewire: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2168
I'm not sure to understand. Do you mean that whenever an application leaves a stream open but unused, VolumeMonitor ends up piling stream objects, until the application does make some use of its stream?
That really looks like a bug that should be fixed in pipewire itself, because:
espeak-ng [...] also suffers the same issue, but stuck/leaked streams are removed once the module starts synthesizing some speech
doesn't really look reasonable either. Within a session speech dispatcher can very well get started (because of some webspeech-triggered invocation for instance), and stay there unused until the user logs out.
It does look like a pipewire specific bug indeed. Check out the last link I posted to their GitLab issue.
I'm not sure to understand. Do you mean that whenever an application leaves a stream open but unused, VolumeMonitor ends up piling stream objects, until the application does make some use of its stream?
Yes, monitoring streams are left opened with a pending state change callback to close them. But state change never happens. And every time user switched to Applications tab, a new monitor stream is created, and when user switches tabs or closes the applet — a stuck stream isn't closed.