I got some advice that maybe conecting both streams with a tee element would resolve the problem, so i tried this: gst-launch -v tee name=near adder name=mixer fakesrc ! identity ! near.sink near.src0 ! queue ! udpsink host=localhost port=5000 near.src1 ! queue ! audio/x-raw-int,rate=44100,channels=1,endianness=1234,width=16,depth=16,signed=true ! queue ! mixer. tee name=far udpsrc port=6000 ! identity ! far.sink far.src0 ! queue ! fakesink far.src1 ! queue ! audio/x-raw-int,rate=44100,channels=1,endianness=1234,width=16,depth=16,signed=true ! queue ! mixer. mixer.src ! fakesink basically i added 2 tees , the tee gets the fakedata and sends it to a fakesink and to a adder, the adder gets the received fakedata from both streams and sends it to a fakesink too. i used queue on the src pad from the tee and on the sinkpads of the adder. Even connecting both streams with the tees + adder seens to not work, both streams got locked. I would expect to not received data on the udpsrc, but the fakesrc stream blocks too. any hint on what is wrong? <div class="gmail_quote">On Wed, Nov 11, 2009 at 9:15 PM, Tiago Katcipis <<a href="mailto:katcipis@inf.ufsc.br">katcipis@inf.ufsc.br</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> I'm building a pipeline to use on a voip application, i started building a very simple one, one stream generates the audio and sends it with udpsink the other receives audio at udpsrc and play it at pulsesink. For test purposes i send the audio to myself. But the odd thing is that it only works when i use separated pipelines to build the send and the receive streams. For example, the following works fine: gst-launch -v audiotestsrc ! identity ! audioconvert ! audio/x-raw-int,rate=44100,channels=1,endianness=1234,width=16,depth=16,signed=true ! udpsink host=127.0.0.1 port=5000 gst-launch udpsrc port=5000 caps="audio/x-raw-int,rate=44100,channels=1,endianness=1234,width=16,depth=16,signed=true" ! identity ! pulsesink But if i use only one pipeline to do the work, it starts just ok....but nothing happens (and no data pass through the identity0 or identity1) gst-launch -v audiotestsrc ! identity ! audioconvert ! audio/x-raw-int,rate=44100,channels=1,endianness=1234,width=16,depth=16,signed=true ! udpsink host=127.0.0.1 port=5000 udpsrc port=5000 caps="audio/x-raw-int,rate=44100,channels=1,endianness=1234,width=16,depth=16,signed=true" ! identity ! pulsesink I think it is something with udpsrc because if i try: gst-launch -v audiotestsrc ! identity ! audioconvert ! audio/x-raw-int,rate=44100,channels=1,endianness=1234,width=16,depth=16,signed=true ! fakesink udpsrc port=5000 caps="audio/x-raw-int,rate=44100,channels=1,endianness=1234,width=16,depth=16,signed=true" ! identity ! pulsesink it will not work too, no data reaches the fakesink. but if i try gst-launch -v audiotestsrc ! identity ! audioconvert ! audio/x-raw-int,rate=44100,channels=1,endianness=1234,width=16,depth=16,signed=true ! udpsink host=127.0.0.1 port=5000 audiotestsrc ! identity ! pulsesink it works just fine. It sens that for some reason the udpsrc makes the entire pipeline stop, no data flows on either streams. I tought it could be some error on pulse with udpsrc, but: gst-launch -v audiotestsrc ! identity ! audio/x-raw-int,rate=44100,channels=1,endianness=1234,width=16,depth=16,signed=true ! fakesink udpsrc port=5000 caps="audio/x-raw-int,rate=44100,channels=1,endianness=1234,width=16,depth=16,signed=true" ! identity ! fakesink wont work either, but if i run on separated gst-launch, it works fine. i even have made some source code to test this, the same example that works on different pipelines wont work if it is made on only one pipeline. The ok code: <a href="https://svn.inf.ufsc.br/katcipis/c/gstreamer/pipe_voip_ok" target="_blank">https://svn.inf.ufsc.br/katcipis/c/gstreamer/pipe_voip_ok</a> The error code: <a href="https://svn.inf.ufsc.br/katcipis/c/gstreamer/pipe_voip_error" target="_blank">https://svn.inf.ufsc.br/katcipis/c/gstreamer/pipe_voip_error</a> the odd thing is that even if udpsrc didn't receive any data, why is udpsrc blocking the entire pipe? hope someone can help me see what I'm doing wrong. best regards, Katcipis </blockquote></div> -- "Se você se perder na selva africana, não precisa se desesperar. Basta sentar em uma pedra e começar a instalar GNU/Linux em seu laptop. Em menos de 5 minutos aparecerá alguém pra discordar de sua escolha de distribuição, do particionamento, do gerenciador de janelas, do ambiente de desktop, do editor de textos..."