[pulseaudio-discuss] [PATCH] add xrdp sink

Tanu Kaskinen tanu.kaskinen at linux.intel.com
Fri May 30 05:43:38 PDT 2014

On Thu, 2014-05-29 at 16:22 -0700, Jay Sorg wrote:
> So we're still left to make a decision.
> 1 - xrdp sink and source as they are except make Alexander's
> changes(everything works).

Is there an xrdp source already written? This patch only implements a

> 2 - esound sink and source as Alexander suggests(source not complete).
> 3 - RTP over unix domain socket(module-rtp-send not complete as
> Laurentiu Nicola says).
> I'm ok with 2 or 3, but I want to make sure it's the best decision
> long term.  I think there will be a lot of users using PA this way.

I don't know the details of any of the three protocols (custom xrdp,
esound or rtp), so I don't have any opinions like "you really should use
X" or "you really shouldn't use Y".

If the esound protocol "deficiencies" (that I'm not familiar with) don't
really matter in case of XRDP, and there's not a lot of mandatory extra
cruft in the protocol that isn't necessary with XRDP, then reusing the
esound protocol sounds like a good idea.

RTP is "standard", which makes it attractive, but it's not clear to me
how much practical benefit it would have. It looks like the existing RTP
modules are not very near to a working solution for XRDP (for starters,
they are designed to be attached to some other sink/source, so the
timing is driven by something else than the other end of the RTP

Hmm, it seems that the sink clock source in the patch is the wall clock.
This seems to defeat the whole point of a custom sink, because you could
as well load module-null-sink and record from its monitor in XRDP using
libpulse. I thought the reason why a special XRDP sink is needed is that
we want to use the client sound card as the clock source, thus avoiding
the need to resample between two clock domains.


More information about the pulseaudio-discuss mailing list