[pulseaudio-discuss] [PATCH] add xrdp sink

[Jay Sorg]

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