[pulseaudio-discuss] [PATCH] add xrdp sink

[Jay Sorg]

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

Yes, I was just trying to keep the patch smaller but as you said, I
didn't need to.

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

Yes, I want to use the client clock.

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

Great, so it seem like we're leaning towards esound.

Jay