Hi, continuing a discussion begun from Felipe this week, I completed my homework to retrieve a testing patch which disables a few mutexes from gst_pad_push (attached) and profile its effects on both ARM and X86 architectures. The first positive surprise is that, even after applying the patch, the following command runs properly on both the architectures: time gst-launch --gst-disable-registry-update audiotestsrc num-buffers=60000 blocksize=128 ! "audio/x-raw-int, rate=8000, width=16" ! audioconvert ! audioconvert ! audioconvert ! fakesink the second effect is that, running the command a few times and getting a statistic set of results, with both optimisation enabled and disabled, I found that the execution time for the command has a mean improvement of about 2.4% on ARM and about 2% on x86 (Intel Atom processor). Here a few outputs: On x86, mutexes disabled: real 0m9.385s user 0m8.773s sys 0m0.076s real 0m9.206s user 0m8.529s sys 0m0.068s mutexes enabled: real 0m9.553s user 0m8.949s sys 0m0.028s real 0m9.669s user 0m9.017s sys 0m0.092s On ARM (omap3430), mutexes disabled: 9.57user 0.07system 0:09.68elapsed 9.63user 0.03system 0:09.71elapsed mutexes enabled: 9.88user 0.07system 0:09.98elapsed 9.80user 0.07system 0:09.90elapsed Considering a mean VoIP pipeline has a number of elements more than double than the ones in my example, the penalty on a real-life stream-engine pipeline should be proportional. Some months ago I was studying a way to detect thread boundaries from within a pipeline and then, in case the application "promises" never to interact with it, to choose an optimised path for gst_path_push (then I dropped the work because of other tasks). Would it be interesting to resume such an approach? P.S. it appears the penalty decreases when buffers have bigger sizes, as <a href="http://felipec.wordpress.com/2010/10/07/gstreamer-embedded-and-low-latency-are-a-bad-combination/">already shown from Felipe</a>. Regards