[pulseaudio-discuss] [PATCH] add xrdp sink
jay.sorg at gmail.com
Thu May 29 16:22:01 PDT 2014
So we're still left to make a decision.
1 - xrdp sink and source as they are except make Alexander's
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.
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.
> 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