<div dir="ltr"><div>Gstreamer 1.16.2; arch linux.</div><div><br></div>Ok, this one is really weird. I've got a media server (written in rust, if that matters) <div>that juggles multiple gstreamer pipelines, with webrtc being the central use case. Occasionally when a browser based peer (google chrome) joins, it receives no audio.<div><br></div><div>The pipeline is pretty basic; an audiotestsrc emits a test tone, encoding as opus, to webrtcbin. The browser side should simply pipe the audio to the local speaker. About 50% of the time, after signalling and ice connectivity has been established, there is no audio. In the cases when there is no audio, I've looked at chrome://webrtc-internals, and the audio track for the browser peer is not receiving any samples; no audio level, audio energy, etc. </div><div><br></div><div>So I've tested a variety of scenarios. If I restart the browser between each test, there is no change. If I restart my media server between each iteration, then I receive audio 100% of the time. I added an identity element after `rtpopuspay` to dump the data to the console, and the data is definitely there. I monitored udp traffic with wireshark; the number and size of packets to the browser is roughly the same when there is audio and when there is not. </div></div><div><br></div><div>So then I turned up gstreamer logging to see if it gave me any insight, and viola! I now have audio 100% of the time. When I set GST_DEBUG to 4 or higher, I get audio on every test iteration. Anything below 3, and the browser emits audio only occasionally. </div><div><br></div><div>Does anyone have insight on what might be going on here?</div></div>