So we're still left to make a decision. 1 - xrdp sink and source as they are except make Alexander's changes(everything works). 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. Jay On Wed, May 28, 2014 at 3:22 PM, Jay Sorg <jay.sorg at gmail.com> wrote: >>> I really want something that is clean, efficient and optimal in design. >> >> >> Good :) but designing clean and efficient things takes time. > > Yes, I've been testing the current xrdp sink for about 6 month. > >>> The source and sink for xrdp now really really work well. They also >>> look good. You can run pavucontrol and see that, yes, the xrdp sink >>> is running. >> >> >> If they work well, then the ESD-protocol sink would also work well (even >> though it is discouraged because of the deficient protocol), because it is >> based on essentially the same protocol. If it doesn't suspend properly, this >> is a bug in PulseAudio that needs to be fixed anyway. >> >> >>> I don't want a TCP or UDP connection for each session or a confusing >>> sink or source name. >> >> >> module-esound-sink works with unix-domain sockets, too, and allows >> overriding the sink name. The problem is that there is no >> module-esound-source, but it is solvable in theory (although I am not sure >> if module-esound-source would be accepted if one submits it). > > I'm a bit concerned to change to the esound way if it's "discouraged > because of the deficient protocol" and there is no source. > > I also see this on the web site. > > vvv > module-esound-sink > > Create a playback sink using an ESOUND server as backend. Whenever you > can, try to omit this module since it has many disadvantages including > bad latency and even worse latency measurement. > > This module lacks the channel_map argument. > > server > > The server to connect to > > cookie > > The authentication cookie file to use. > ^^^ > > The more I look at it, the more I don't like the esound route. Can > you make esound a priority and guarantee the source will be accepted? > If not, I don't see how esound can work. > > What do you other guys think? > > Jay
