On Mon, 2013-03-25 at 19:24 +0000, Arun Raghavan wrote: > I wouldn't look at using GStreamer in pulsecore. It wouldn't act as a > native protocol replacement. Instead, I visualise things working > something like this: > > ----- > C | | > l | | -------------- > i ---> | P | | | > e ---> | A |---> | Gst RTP sink | ... network ... > n ---> | | | | > t | | -------------- > s | | > ----- > ----- > | | > ---------------- | | ----------------- > | | | P | | | > ... | Gst RTP source | ---> | A | ---> | Client/loopback | > | | | | | | > ---------------- | | ---------------- > | | > ----- > > The RTP sink would very roughly be a GStreamer pipeline like: > > appsrc ! opusenc ! rtpopuspay ! rtpbin > > And the RTP source would very roughly be: > > rtpbin ! rtpopusdepay ! opusdec ! appsink > > The app* elements would provide/consume PCM data to/from the PulseAudio > source/sink modules. The module could hook into the rtpbin to get RTCP > data/stats and poke at the encoder appropriately. Out of curiosity: do the RTP/RTCP protocols and GStreamer's implementation of them support a setup where the Gst RTP source would be replaced with a sink input, and the Gst RTP sink would adapt its sending rate to the rate at which the remote machine consumes the data? The idea of course would be avoiding the loopback, and thus resampling, in the receiving machine. > The frequency and > precision of RTCP (Something seems to be missing here.) -- Tanu
