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 719356 - critical warning _gst_util_uint64_scale in gst_pulsering_stream_latency_cb
critical warning _gst_util_uint64_scale in gst_pulsering_stream_latency_cb
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.2.1
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-11-26 13:38 UTC by Dirk-Jan C. Binnema
Modified: 2016-09-05 14:24 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
python test (555 bytes, text/x-python)
2013-12-05 00:35 UTC, Olivier Crête 		Details
apport dump (3.16 MB, application/x-xz)
2016-09-05 14:24 UTC, Marcin Lewandowski 		Details

Description Dirk-Jan C. Binnema 2013-11-26 13:38:38 UTC 
When playing a bit with a GstControlSource to fade volume over time, I got the below error; the same thing works find with an AlsaSink and in fact it does seem to work with the PulseSink as well, except for this critical warning.

(test-player:23687): GStreamer-CRITICAL **: _gst_util_uint64_scale: assertion 'denom != 0' failed

Program received signal SIGTRAP, Trace/breakpoint trap.

+ Trace 232839

Thread 140736934696704 (LWP 23753)

  • #0 g_logv
    at gmessages.c line 989
  • #1 g_log
    at gmessages.c line 1025
  • #2 g_return_if_fail_warning
    at gmessages.c line 1034
  • #3 _gst_util_uint64_scale
    at gstutils.c line 479
  • #4 gst_pulsering_stream_latency_cb
    at pulsesink.c line 721
  • #5 stream_get_timing_info_callback
    at pulse/stream.c line 1944
  • #6 run_action
    at pulsecore/pdispatch.c line 279
  • #7 pa_pdispatch_run
    at pulsecore/pdispatch.c line 331
  • #8 pstream_packet_callback
    at pulse/context.c line 335
  • #9 do_read
    at pulsecore/pstream.c line 830
  • #10 do_pstream_read_write
    at pulsecore/pstream.c line 185
  • #11 dispatch_pollfds
    at pulse/mainloop.c line 656
  • #12 pa_mainloop_dispatch
    at pulse/mainloop.c line 903
  • #13 pa_mainloop_iterate
    at pulse/mainloop.c line 934
  • #14 pa_mainloop_run
    at pulse/mainloop.c line 949
  • #15 thread
    at pulse/thread-mainloop.c line 90
  • #16 internal_thread_func
    at pulsecore/thread-posix.c line 83
  • #17 start_thread
    at pthread_create.c line 309
  • #18 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 111 






Comment 1


Olivier Crête





          2013-11-28 22:42:01 UTC
        



Do you have some example code that can reproduce this problem? The volume property on pulsesink is not controllable.






Comment 2


Dirk-Jan C. Binnema





          2013-12-03 23:02:36 UTC
        



Yeah, there's another volume-element in the pipeline to do the controlling.

It's a bit tricky to create a small test-case though... is there a way to do the controlling using gst-launch? 

(also, note that this problems seems to have come up with with fairly recent gstreamers, perhaps with 1.2?)






Comment 3


Olivier Crête





          2013-12-04 16:00:05 UTC
        



what is your pipeline? what control points are you applying to which element ?






Comment 4


Dirk-Jan C. Binnema





          2013-12-04 17:22:12 UTC
        



Pipeline looks like something like:

gst-launch-1.0 filesrc location=/home/djcb/Music/track.ogg ! decodebin !  equalizer-10bands ! volume ! pulsesink

(I say 'something like' since the filesrc + decodebin is actually a playbin in the app, gst-launch doesn't allow me to specify the audio-sink property)

I'm controlling the volume-element (I'm actually using two pipelines, and implement cross-fading by changing the volume in opposite directions). 

Looking at the code, (gstvolume.c), I suppose the 'rate' parameter is zero for some reason. I'm not doing anything with the rate though.






Comment 5


Olivier Crête





          2013-12-05 00:35:16 UTC
        



Created attachment 263556 [details]
python test

The attached test script seems to work perfectly. Does it fail with any file? or only specific ones ?






Comment 6


Dirk-Jan C. Binnema





          2013-12-05 02:54:55 UTC
        



Oh, thanks for the effort! Can't reproduce it with that script; I'll try if I can modify it a bit so the problem is triggered.






Comment 7


André Klapper





          2015-01-24 09:04:15 UTC
        



(In reply to comment #6)
> Can't reproduce it with that script; I'll try if I
> can modify it a bit so the problem is triggered.

djcb: Still the case?






Comment 8


Dirk-Jan C. Binnema





          2015-01-25 21:38:14 UTC
        



Haven't seen this for quite a while -- feel free to close. Thanks!






Comment 9


Tim-Philipp Müller





          2015-01-26 09:15:46 UTC
        



Thanks!






Comment 10


Marcin Lewandowski





          2016-09-05 14:20:18 UTC
        



I have just encountered the same. Unfortunately, there was no core dump.

My pipeline is 

pulsesrc ! audioconvert ! audioresample  ! audiocheblimit mode=1 cutoff=80 ! level post-messages=true interval=80ms ! fakesink sync=true silent=true

I will try to catch core dump






Comment 11


Marcin Lewandowski





          2016-09-05 14:24:17 UTC
        



My GStreamer version is 1.8.2. Using Ubuntu Linux 16.04. It seems that appport has caught stacktrace.






Comment 12


Marcin Lewandowski





          2016-09-05 14:24:33 UTC
        



Created attachment 334810 [details]
apport dump