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 0x7fb4fdefe32f in __GI___poll (fds=fds@entry=0x7fb4f40071a0,
> nfds=nfds@entry=2, timeout=timeout@entry=1500) at
> ../sysdeps/unix/sysv/linux/poll.c:29
> #1 0x7fb4fe0652e1 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 0x7fb4fe056fa4 in pa_mainloop_poll (m=m@entry=0x56184db545b0) at
> ../src/pulse/mainloop.c:863
> #4 0x7fb4fe057606 in pa_mainloop_iterate (m=m@entry=0x56184db545b0,
> block=block@entry=1, retval=retval@entry=0x0) at ../src/pulse/mainloop.c:945
> #5 0x7fb4fe0576b0 in pa_mainloop_run (m=0x56184db545b0,
> retval=retval@entry=0x0) at ../src/pulse/mainloop.c:963
> #6 0x7fb4fe0653b9 in thread (userdata=0x56184db54560) at
> ../src/pulse/thread-mainloop.c:101
> #7 0x7fb4fd5d433f in internal_thread_func (userdata=0x56184db5ad20) at
> ../src/pulsecore/thread-posix.c:81
> #8 0x7fb4fde8784a in start_thread (arg=) at
> ./nptl/pthread_create.c:442
> #9 0x7fb4fdf0b2cc 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.
#include
#include
#include
#include
int main(void) {
pa_buffer_attr buffAttr;
pa_sample_spec ss;
int error;
int sample_rate = 44100;
int num_channels = 1;
int bytes_per_sample = 2;
ss.rate = sample_rate;
ss.channels = num_channels;
ss.format = PA_SAMPLE_S16LE;
buffAttr.maxlength = (uint32_t) - 1;
buffAttr.tlength = 10 * sample_rate * num_channels * bytes_per_sample / 1000;
buffAttr.prebuf = (uint32_t) - 1;
buffAttr.minreq = (uint32_t) - 1;
buffAttr.fragsize = (uint32_t) - 1;
pa_simple * simple = pa_simple_new(NULL, "test",
PA_STREAM_PLAYBACK, NULL, "playback",
, NULL, , );
if (!simple) {
fprintf(stderr,"error: %s\n", pa_strerror(error));
}
while (1)
pause();
}
