GNOME Bugzilla – Bug 578506
Pipeline with alsasrc and alsasink cannot change state back to playing
Last modified: 2009-08-24 14:34:53 UTC
Please describe the problem: I have a simple pipeline with the following elements: alsasrc->audioconvert->capsfilter->audioconvert->alsasink Steps to reproduce: Recreate the above pipeline (I'll attach a testcase), and asynchronously change the pipeline state from playing to null to playing. Actual results: The pipeline will go to null, but then not go back to playing. It seems to hang on GST_STATE_CHANGE_ASYNC Expected results: It would go back to playing. Does this happen every time? Yes. Other information: The same thing also happens if you substitute alsasrc/sink with jackaudiosrc/sink
Created attachment 132414 [details] testcase for state change uses gtk as well as gstreamer
commit dffd1bcc976c432d3827a0a9a34f5ad24edec3d9 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Tue Apr 14 13:16:14 2009 +0200 baseaudiosrc: adjust the internal timestamp Adjust the internal timestamp before comparing it against the adjusted clock time. Fixes #578506 commit 0c4c1410f970bca4857acd03527772454dc76e52 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Tue Apr 14 13:12:59 2009 +0200 baseaudiosink: use new clock time methods Use the unadjusted internal clock times to calculate the internal/external offset when calibrating the clock. When going to NULL, unparent and free the ringbuffer, like we do in the source element. See #578506 commit 4231d54823b9811152d9c7e42e293a5e379a3c4b Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Tue Apr 14 13:08:52 2009 +0200 audioclock: add methods for the internal offset Add two methods for getting the unadjusted time of the clock and one for adjusting an internal time. We will need these methods for correctly handling the time after a gst_audio_clock_reset(). Add a debug category and some debug lines to the audio clock. API: gst_audio_clock_get_time() API: gst_audio_clock_adjust() API: GST_AUDIO_CLOCK_CAST()
*** Bug 590678 has been marked as a duplicate of this bug. ***