GNOME Bugzilla – Bug 571314
skewing audio sink results in zero input
Last modified: 2010-03-28 15:30:26 UTC
While doing a test input from usb microphone on webcam random noises eventually arrise and then the audio will abrubtly stop and never picks up again. GST_DEBUG=*:2 0:06:35.673672742 25015 0x827c610 WARN baseaudiosink gstbaseaudiosink.c:914:gst_base_audio_sink_skew_slaving:<alsasink3> correct clock skew 5810306 > 5804500 0:06:35.684449193 25015 0x827c610 WARN baseaudiosink gstbaseaudiosink.c:938:gst_base_audio_sink_skew_slaving:<alsasink3> correct clock skew -5846918 < -5804500 the first one always seems to appear first, then it will repeat this untill you hit stop. Simple fix gst-plugins-base-0.10.21/gst-libs/gst/audio/gstbaseaudiosink.c line 1325 if ((slaved = clock != sink->provided_clock)) { changed to slaved = (clock != sink->provided_clock); slaved = FALSE;//BUGFIX if (slaved) { ..has been working without any noise artifacts and without dropping out for 20+ mins now. It used to last 5 mins tops, with popping artifacts. On FreeNode someone with latest version, 0.10.22, says he has the same skewing problems and audio dropping out
I was using device=plughw:1,0 so who knows about sample rate. when I had GST_DEBUG=*:2 it would do a constant popping noise unless I had " ! queue" added to the custom pipeline. After this patch I no longer need such an alteration.
scratch the last comment, I guess I still need " ! queue" sometimes
Disabling the clock slaving is not a good idea, it will cause synchronisation problems when dealing with VOIP or RTSP streaming media. The problem here is that the audio clock exposed by the source element is not very accurate and the sink has trouble slaving to it. There have been a lot of changes since this bug was reported. Does it still happen with latest versions?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!