Latency of 10001ms causes std::logic_error at 192khz sample rate with sine wave

[xtknight]

I noticed when changing latency to 10001ms, I get a std::logic_error when playing a sine wave test. Anyways, the point isn't that I care about the sine wave test crashing, but want to make sure there's no deeper issue here.

In PulseAudio daemon.conf, the setting default-sample-rate = 192000 seems to cause the problem. If I don't use this, the problem seems not to happen. Also, it sometimes only happens when I restart pulseeffects and play the sine wave straight away.

I can't find much information about this error. When I try to trace in gdb, I get something like this:

Thread 1 "pulseeffects" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x00007f092c339e97 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007f092c33b801 in __GI_abort () at abort.c:79
#2 0x00007f092cf4d8fb in () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007f092cf53d3a in () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007f092cf53d95 in () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007f092cf53fe8 in () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x0000562a78b12e0d in ()
#7 0x0000562a78bcfb12 in ()
#8 0x00007f092b5b3dae in ffi_call_unix64 () at /usr/lib/x86_64-linux-gnu/libffi.so.6
#9 0x00007f092b5b371f in ffi_call () at /usr/lib/x86_64-linux-gnu/libffi.so.6
#10 0x00007f09300ce761 in g_cclosure_marshal_generic () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#11 0x00007f09300cdf6d in g_closure_invoke () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#12 0x00007f09300e0d3e in () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#13 0x00007f09300e93f5 in g_signal_emit_valist () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#14 0x00007f09300e9e0f in g_signal_emit () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#15 0x00007f092db35e84 in gst_bus_async_signal_func () at /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#16 0x00007f092db36cad in () at /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#17 0x00007f09305de0f5 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#18 0x00007f09305de4c0 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x00007f09305de54c in g_main_context_iteration () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#20 0x00007f092f2b5d2d in g_application_run () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#21 0x0000562a78abc5cc in main ()

I've attached logs of a normal 10000ms run and a 10001ms run where the exception occurs.
G_MESSAGES_DEBUG=pulseeffects GST_DEBUG=4 pulseeffects

normal_log_10000.txt
logic_error_log_10001.txt

1. Distribution and Desktop Environment: Ubuntu 18.04 LTS, MATE Desktop
2. PulseEffects: dpkg 4.2.2-1~bionic1, Mikhail Novosyolov mikhailnov@dumalogiya.ru
3. Logs attached

[wwmm]

If you do not use 10001 ms everything is fine?

Latency is a little tricky to set. People have had problems with it over time. GStreamer documentation doesn't say which latency values are really valid for pulsesrc. I imagine that there must be some relation between the latency and the buffer parameters. Maybe one of them has to be a multiple of the other. The truth is that we are really in the dark in this situation. I asked about this once in GStreamer mailing list but I've got no answer

[xtknight]

I see...that's unfortunate. So far, I've only been able to reproduce using 10001ms, 192kHz, and the test signal generator. I'll update if I have any other details but this exception seems to only happen in special cases.

[wwmm]

As the fix for this should probably be done in pulsesrc I will close this issue