[pulseaudio-discuss] GSoC: Call for project ideas

[Tanu Kaskinen]

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