[pulseaudio-discuss] [PATCH] add xrdp sink
Alexander E. Patrakov
patrakov at gmail.com
Fri May 30 07:54:56 PDT 2014
30.05.2014 18:43, Tanu Kaskinen пишет:
> 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
Yes, there is.
>> 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".
I have a draft mail on this topic, will finish and send it out later
today. It would help (to shorten the e-mail) if Jay Sorg confirms that
we indeed want to use the client sound card as the clock source.
> 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.
I agree here. Also, module-esound-source would be useful anyway even
without any relation to xrdp, so that's a cheap experiment that would
leave no cruft in PulseAudio even if it fails for xrdp.
> 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
For me, esound is "standard" in the same sense. There are both
advantages and disadvantages in RTP as compared to esound, as well as
> 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.
Indeed, RTP, in any form, unconditionally forces one to use the local
clock source and add an adaptive resampler on the receiving end. A
rather complex solution, I'd say.
But I don't agree that the ability to use the existing RTP modules would
defeat the whole point of the patch. Nice sink names in pavucontrol are
definitely a benefit, and that's why it is definitely a good idea,
independently from any xrdp-related stuff, to implement a real RTP sink
and source, not needing the null-sink trickery.
Alexander E. Patrakov
More information about the pulseaudio-discuss