Bug#1022119: [Tts-project] Bug#1022120: speech-dispatcher-dummy causes pipewire to spin and use battery

[Samuel Thibault]

Control: reassign 1022120 pipewire

Hello,

Both bugs 1022119 ("Wakes up every 1.5s even with no work to do") and
1022120 ("causes pipewire to spin and use battery") can easily be
reproduce with the attached very simple testcase. It thus doesn't seem
to me it is a bug in speech-dispatcher.

Josh Triplett, le jeu. 20 oct. 2022 13:54:48 +0100, a ecrit:
> I discovered pw-top, and it showed that
> speech-dispatcher-dummy was the only thing interacting with pipewire.
> Killing speech-dispatcher caused pipewire to *stop* waking up and using
> battery.
> 
> To the best of my knowledge, nothing on my system should be *using*
> speech-dispatcher. (Happy to check that if there's a tool to do so.)

firefox & chrome happen to trigger speech-dispatcher for supporting
the Web Speech API.

> So it shouldn't be sending anything to pipewire and causing pipewire
> to wake up.

As the testcase shows, even not sending anything to pipewire triggers
the concern, so the issue doesn't seem to be on the application side.

Samuel

Samuel Thibault, le jeu. 20 oct. 2022 15:24:48 +0200, a ecrit:
> Samuel Thibault, le jeu. 20 oct. 2022 15:02:09 +0200, a ecrit:
> > Josh Triplett, le jeu. 20 oct. 2022 13:45:45 +0100, a ecrit:
> > > sd_dummy seems to be waking up every 1.5s even when it has no work to
> > > do.
> > 
> > I don't see that happening on my system. Could you run strace on it so
> > we get to know what happens in your case? E.g.
> > 
> > strace -p $(pgrep sd_dummy)
> 
> Ah, -f is needed to see the thread started by pulseaudio.
> 
> (gdb) bt
> #0  0x00007fb4fdefe32f in __GI___poll (fds=fds at entry=0x7fb4f40071a0, nfds=nfds at entry=2, timeout=timeout at entry=1500) at ../sysdeps/unix/sysv/linux/poll.c:29
> #1  0x00007fb4fe0652e1 in poll (__timeout=1500, __nfds=2, __fds=0x7fb4f40071a0) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
> #2  poll_func (ufds=0x7fb4f40071a0, nfds=2, timeout=1500, userdata=0x56184db546b0) at ../src/pulse/thread-mainloop.c:70
> #3  0x00007fb4fe056fa4 in pa_mainloop_poll (m=m at entry=0x56184db545b0) at ../src/pulse/mainloop.c:863
> #4  0x00007fb4fe057606 in pa_mainloop_iterate (m=m at entry=0x56184db545b0, block=block at entry=1, retval=retval at entry=0x0) at ../src/pulse/mainloop.c:945
> #5  0x00007fb4fe0576b0 in pa_mainloop_run (m=0x56184db545b0, retval=retval at entry=0x0) at ../src/pulse/mainloop.c:963
> #6  0x00007fb4fe0653b9 in thread (userdata=0x56184db54560) at ../src/pulse/thread-mainloop.c:101
> #7  0x00007fb4fd5d433f in internal_thread_func (userdata=0x56184db5ad20) at ../src/pulsecore/thread-posix.c:81
> #8  0x00007fb4fde8784a in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
> #9  0x00007fb4fdf0b2cc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
> 
> so that's coming from pulseaudio. The 1500 delay is most probably
> coming from
> 
> ./src/pulse/stream.c:#define AUTO_TIMING_INTERVAL_END_USEC (1500*PA_USEC_PER_MSEC)
> 
> I don't know why pulseaudio would be waking up every 1.5s even if the
> speech module doesn't submit any audio.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.c
Type: text/x-csrc
Size: 771 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-pulseaudio-devel/attachments/20221022/11441d1f/attachment-0001.c>