After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 580007 - GstRingbuffer throws a floating point exception when buffer-time is too low
GstRingbuffer throws a floating point exception when buffer-time is too low
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other All
: Normal critical
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-04-23 18:25 UTC by Tristan Matthews
Modified: 2010-03-18 20:55 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24


Attachments
testcase for ringbuffer floating point exception (4.18 KB, text/plain)
2009-04-23 18:30 UTC, Tristan Matthews
Details

Description Tristan Matthews 2009-04-23 18:25:48 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.

Thread 3069389712 (LWP 14195)

  • #0 gst_ring_buffer_prepare_read
    at gstringbuffer.c line 1894
  • #1 jack_process_cb
    at gstjackaudiosink.c line 209
  • #2 jack_process_cb
    at gstjackaudioclient.c line 103
  • #3 jack_client_thread
    at client.c line 1601
  • #4 jack_thread_proxy
    at thread.c line 110
  • #5 start_thread
    from /lib/tls/i686/cmov/libpthread.so.0
  • #6 clone
    from /lib/tls/i686/cmov/libc.so.6


Other information:
Comment 1 Tristan Matthews 2009-04-23 18:30:02 UTC
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
Comment 2 Tristan Matthews 2009-04-23 20:44:26 UTC
it appears that in gstringbuffer.c at line 1894, buf->spec.segtotal == 0, which leads to the floating point exception.
Comment 3 Wim Taymans 2009-04-24 17:35:35 UTC
Is this a regression?
Comment 4 Tristan Matthews 2009-04-24 17:42:43 UTC
I don't think so, I hadn't tested it until fairly recently though.
Comment 5 Wim Taymans 2009-04-27 15:44:42 UTC
You can't set the buffer-time less than the latency-time. did you change the latency-time too?
Comment 6 Tristan Matthews 2009-04-27 16:57:14 UTC
Even if I change the latency time to be less than the buffer-time, I get the same failure. 
Comment 7 Tristan Matthews 2009-04-28 18:57:48 UTC
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]
Comment 8 Tristan Matthews 2009-04-28 19:08:15 UTC
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?
Comment 9 Tristan Matthews 2010-03-18 20:50:47 UTC
This seems to have been fixed, unfortunately I can't really tell when.
Comment 10 Tim-Philipp Müller 2010-03-18 20:55:50 UTC
Let's mark it as obsolete then :)