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
