[pulseaudio-discuss] [PATCH] add xrdp sink

[Alexander E. Patrakov]

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
> sink.

Yes, there is.

https://github.com/neutrinolabs/xrdp/blob/devel/sesman/chansrv/pulse/module-xrdp-source.c


>
>> 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
> stream).

For me, esound is "standard" in the same sense. There are both 
advantages and disadvantages in RTP as compared to esound, as well as 
mere differences.

> 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