[pulseaudio-discuss] [PATCH] add xrdp sink
jay.sorg at gmail.com
Wed May 28 15:22:30 PDT 2014
>> 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.
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.
The server to connect to
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?
More information about the pulseaudio-discuss