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