GNOME Bugzilla – Bug 347296
Problems with clocks on alsasrc hangs the application
Last modified: 2006-07-12 13:25:12 UTC
Steps to reproduce: We are having a problem in Jokosher when it comes to recording. Basically, I create a new project, add a track, arm the track (press the record button on the track), hit the main record button and it records fine. If I then try to record again, Jokosher hangs. This is a problem in recent CVS GStreamer. This is a blocker bug for Jokosher before our 0.1 freeze on 15th July. Laszlo did some debugging into this, and here are his notes: --- Okay here's how it goes: -Pipeline is NULL -recordingbin is added to pipeline (no problems) -Pipeline changes to READY then PAUSED then PLAY (all successful as far as I can tell in the gstdebug log) -I hit stop, the Pipeline is set to NULL (in current SVN it is set to READY, which one should it be?) -recordingbin is removed from the pipeline (the current code removes it before setting the pipeline to READY but I switched these around on my local copy) -I delete the event that was just recorded leaving the armed instrument empty. -the pipeline is still NULL, I hit record. -Project.record() calls instrument.record() -I put a gst.debug() statement right before the recordingbin is added to the pipeline. -instrument.record() tries to add recordingbin to the pipeline. Jokosher freezes. There is only one debug message in the log between the one I sent and the end of the file (where it crashed): WARN (0x826cc18 - 0:00:18.817043000) baseaudiosrc(11529) gstbaseaudiosrc.c(168):gst_base_audio_src_set_clock:<alsasrc1> error: Cannot operate with this clock. Wtf? What changed about the clock between when it worked and when it didn't? Well, I hope this helps. I'm at work tomorrow and I have to IRC until the evening, but I will be monitoring the logs. --- Stack trace: Other information:
I forgot to say, the problem occurs recording the second time in all scenarios - with a single track or multiple tracks.
Created attachment 68807 [details] [review] patch to fix deadlock when adding a clock consumer to a bin, the currently configured clock is set on the element. In this case the current clock was the clock of the previous source. The new audio source does not accept that clock and posts an error message. This deadlocks because it needs to acquire the lock on the parent which is taken because an element is being added to the bin. This patch does not post an error when this happens.
* gst-libs/gst/audio/gstbaseaudiosrc.c: (gst_base_audio_src_set_clock), (gst_base_audio_src_check_get_range), (gst_base_audio_src_create): Don't try to post an error message when setting the clock fails as this can happen when adding an element to a bin which will then deadlock. Fixes #347296.