[pulseaudio-discuss] [PATCH] add xrdp sink
jay.sorg at gmail.com
Fri May 30 10:52:19 PDT 2014
>> Is there an xrdp source already written? This patch only implements a
> Yes, there is.
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
> 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.
More information about the pulseaudio-discuss