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 590678 - pulseaudiosrc doesn't come back online after stopping then starting
pulseaudiosrc doesn't come back online after stopping then starting
Status: RESOLVED DUPLICATE of bug 578506
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
0.10.x
Other Linux
: Normal critical
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-08-03 20:15 UTC by Ben Limmer
Modified: 2009-08-24 14:36 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26

Attachments
small code segment that properly reproduces the bug (1.31 KB, text/x-c++src)
2009-08-04 20:45 UTC, Ben Limmer 		  Details
possible patch (967 bytes, patch)
2009-08-24 14:36 UTC, Wim Taymans 		none Details | Review

Description Ben Limmer 2009-08-03 20:15:20 UTC 
when using a simple pipeline such as pulsesrc ! capsfilter ! rgvolume ! queue ! autoaudiosink, the audio plays back fine the first time, however if I set the pipeline's state to NULL, wait a second, then start it up again, no information is played back anymore.
Comment 1 Sebastian Dröge (slomo) 2009-08-04 11:02:56 UTC 
Could you attach some sample code to reproduce this behaviour?
Comment 2 Ben Limmer 2009-08-04 20:45:47 UTC 
Created attachment 139906 [details]
small code segment that properly reproduces the bug

In the command declaration, you will need to change the device= to whatever pulsesrc is attached to your machine. When you run the program, you should notice the audio plays back just find when I first startup the pipeline, but when you set the pipeline's state to null, then back to started up, the audio will only playback for about half a second before it stops playing back completely. Email me with any questions you have.
Comment 3 Sebastian Dröge (slomo) 2009-08-14 09:24:48 UTC 
Yes, I can reproduce it here. gdb output and backtrace is is:

Assertion 's' failed at pulse/stream.c:1932, function pa_stream_cork(). Aborting.

Program received signal SIGABRT, Aborted.
(gdb) bt

+ Trace 216923

  • #0 *__GI_raise
    at ../nptl/sysdeps/unix/sysv/linux/raise.c line 64
  • #1 *__GI_abort
    at abort.c line 88
  • #2 pa_stream_cork
    at pulse/stream.c line 1933
  • #3 gst_pulsesrc_set_corked
    at pulsesrc.c line 1101
  • #4 gst_pulsesrc_play
    at pulsesrc.c line 1144
  • #5 gst_pulsesrc_change_state
    at pulsesrc.c line 1183
  • #6 gst_element_change_state
    at gstelement.c line 2547
  • #7 gst_element_set_state_func
    at gstelement.c line 2503
  • #8 gst_bin_element_set_state
    at gstbin.c line 2046
  • #9 gst_bin_change_state_func
    at gstbin.c line 2334
  • #10 gst_element_change_state
    at gstelement.c line 2547
  • #11 gst_element_set_state_func
    at gstelement.c line 2503
  • #12 gst_bin_element_set_state
    at gstbin.c line 2046
  • #13 gst_bin_change_state_func
    at gstbin.c line 2334
  • #14 gst_pipeline_change_state
    at gstpipeline.c line 467
  • #15 gst_element_change_state
    at gstelement.c line 2547
  • #16 gst_element_change_state
    at gstelement.c line 2591
  • #17 gst_element_change_state
    at gstelement.c line 2584
  • #18 gst_element_set_state_func
    at gstelement.c line 2503
  • #19 main 

Wim, any ideas?
Comment 4 Sebastian Dröge (slomo) 2009-08-14 09:28:52 UTC 
Hm, that's only when providing an invalid device... but it still shouldn't explode then ;)

When providing a valid device it works but I can't test it here because I have no microphone, sorry
Comment 5 Wim Taymans 2009-08-24 14:34:53 UTC 

*** This bug has been marked as a duplicate of bug 578506 ***
Comment 6 Wim Taymans 2009-08-24 14:36:22 UTC 
Created attachment 141558 [details] [review]
possible patch

A possible patch for the weird assertion.