GNOME Bugzilla – Bug 420915
Playback problem with two alsasinks
Last modified: 2007-03-22 11:38:26 UTC
Having a pipeline like this: src1 -+-> adder -> tee +-> sink1 src2 -´ `-> sink2 On the second output there is always a crackling noise -- no matter which soundcard is choosen as second. The first output is fine. I first thought it could have something to do with the adder/tee combination, but here is a simple testcase for the commandline, without adder and tee: gst-launch-0.10 audiotestsrc ! audioconvert ! alsasink device=hw:0 \ audiotestsrc ! audioconvert ! alsasink device=hw:1 You may exchange the device numbers, it's always the first defined device that crackles. When sending it to two wav files, there is no problem: gst-launch-0.10 audiotestsrc ! audioconvert ! wavenc ! filesink location=1.wav \ audiotestsrc ! audioconvert ! wavenc ! filesink location=2.wav
Created attachment 85021 [details] Adder/Tee Example Here is the C example with the first mentioned pipeline with adder and tee and two alsasinks.
I imagine this is probably caused by clock slaving - the 2nd alsasink is going to be supplying the master clock, and the 2nd one will be trying to adjust so that both are playing at precisely the correct rate. What version of gstreamer Base Plugins do you have? (gst-inspect-0.10 alsasink should tell you)
With 0.10.10 on Ubuntu Edgy I've get this noise on the second device. With 0.10.12 on Ubuntu Feisty the second device plays for a short time without noise followed by silence, while the first output plays on. Here is the output: New clock: GstAudioSinkClock WARNING: from element /pipeline0/alsasink1: Compensating for audio synchronisation problems Additional debug info: gstbaseaudiosink.c(860): gst_base_audio_sink_render (): /pipeline0/alsasink1: Unexpected discontinuity in audio timestamps of more than half a second (0:00:00.719795918), resyncing WARNING: from element /pipeline0/alsasink1: Compensating for audio synchronisation problems Additional debug info: gstbaseaudiosink.c(860): gst_base_audio_sink_render (): /pipeline0/alsasink1: Unexpected discontinuity in audio timestamps of more than half a second (0:08:05.554648526), resyncing Caught interrupt -- handling interrupt. Execution ended after 8129491000 ns. And here more details (with GST_DEBUG=3): 0:00:00.771244000 26554 0x81147a0 WARN baseaudiosink gstbaseaudiosink.c:860:gst_base_audio_sink_render:<alsasink1> warning: Compensating for audio synchronisation problems 0:00:00.771376000 26554 0x81147a0 WARN baseaudiosink gstbaseaudiosink.c:860:gst_base_audio_sink_render:<alsasink1> warning: Unexpected discontinuity in audio timestamps of more than half a second (0:00:00.719795918), resyncing 0:00:00.771485000 26554 0x81147a0 INFO GST_ERROR_SYSTEM gstelement.c:1590:gst_element_message_full:<alsasink1> posting message: Compensating for audio synchronisation problems 0:00:00.771829000 26554 0x81147a0 INFO GST_ERROR_SYSTEM gstelement.c:1613:gst_element_message_full:<alsasink1> posted warning message: Compensating for audio synchronisation problems
Hmm, I'm not really an audio pro -- and thinking about this issue... is this even possible to implement this because of the clock synchronization of the two soundcards? I've just looked at Jack and saw that it's also very hard to get two soundcards working...
Problem solved: The synchronization of the alsasink elements has to be turned off. Here is an example: audiotestsrc ! audioconvert ! audioresample ! tee name=t \ t.src1 ! queue ! alsasink sync=false device=hw:0 \ t.src2 ! queue ! alsasink sync=false device=hw:1 Thanks to Christophe Dehais on the mailinglist!
Yes, that'll solve it, because both audio devices will be running independently. Over time, you'll find that they'll drift out of sync, and you won't be able to play lip-synced video with sync turned off. The real problem is that you can hear alsasink adjusting to fit the other sink's clock - resampling the outgoing audio would fix that, but needs implementing in the audio sinks.