GNOME Bugzilla – Bug 580007
GstRingbuffer throws a floating point exception when buffer-time is too low
Last modified: 2010-03-18 20:55:50 UTC
Steps to reproduce: Write a gst application with an audiosink that has a gstringbuffer, i.e. jackaudiosink, and set its "buffer-time" property to something under 10000. Stack trace: gdb gives this information: [Thread debugging using libthread_db enabled] [New Thread 0xb72008d0 (LWP 14189)] [New Thread 0xb6f32b90 (LWP 14195)] [New Thread 0xb6eb1b90 (LWP 14196)] [New Thread 0xb64ffb90 (LWP 14197)] Program received signal SIGFPE, Arithmetic exception.
+ Trace 214733
Thread 3069389712 (LWP 14195)
Other information:
Created attachment 133201 [details] testcase for ringbuffer floating point exception compile with: g++ `pkg-config gstreamer-0.10 gtk+-2.0 --cflags --libs` test.c -o test
it appears that in gstringbuffer.c at line 1894, buf->spec.segtotal == 0, which leads to the floating point exception.
Is this a regression?
I don't think so, I hadn't tested it until fairly recently though.
You can't set the buffer-time less than the latency-time. did you change the latency-time too?
Even if I change the latency time to be less than the buffer-time, I get the same failure.
I did more testing, and I've found that the minimum value you can assign to buffer-time without getting this exception depends on (at least) your jack server's frames per period setting as well as its sample rate, both of which can be determined with jack_get_buffer_size and jack_get_sample_rate, respectively. For example, for a sample rate of 48000, the following combinations represent the minimum buffer-times possible: sample-rate: 48000 frames per period: [16 32 64 128 256 512 1024 2048] min buffer-time: [333 666 1333 2666 5333 10666 21333 42666] or for 44100... sample-rate: 44100 frames per period: [16 32 64 128 256 512 1024 2048] min buffer-time: [362 725 1451 2902 5804 11609 23219 46439]
so the formula for the minimum is: N frames * 1sec/samplerate * 1000000usec/sec = min buffertime, i.e. 64 frames/1 sec X 1 sec/48000 frames * 1000000 usecs/sec = 1333.3333 should i patch jackaudiosink and jackaudiosrc to make sure that one can't set the buffer-time property below this value?
This seems to have been fixed, unfortunately I can't really tell when.
Let's mark it as obsolete then :)