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