speech-dispatcher-dummy stream can not be monitored, stuck in PA_STREAM_CREATING state

[ratijas]

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

[sthibaul]

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.

[ratijas]

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.