[PATCH] add xrdp sink

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 2014-05-31 at 02:05 +0600, Alexander E. Patrakov wrote:
> 30.05.2014 18:43, Tanu Kaskinen wrote:
> >> 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.
> >
> > I don't know the details of any of the three protocols (custom xrdp,
> > esound or rtp), so I don't have any opinions like "you really should use
> > X" or "you really shouldn't use Y".
> 
> OK, here are some bad words about the protocols.
> 
> The main reason why I am currently against the current custom protocol is:
> 
> Any custom protocol will likely evolve, and, with the current inability 
> to build out-of-tree modules, it means that future versions of both xrdp 
> and PulseAudio will have to deal somehow with any resulting version 
> mismatch. The current protocol doesn't provide any versioning, though, 
> and that's a problem _if_ the custom protocol (as opposed to a suitable 
> but set-in-stone standard protocol) is accepted as the way forward.

It would be good to be able to extend the esound protocol too without
breaking compatibility. While it looks like there's no explicit
extension/versioning mechanisms in the esound protocol, it seems that
the authentication phase could be abused for that. The esound client
first sends the authentication cookie, and the esound server sends a
32-bit integer as a reply where 0 means failure and non-zero means
success. In practice I suppose the reply will normally be 1. If it ever
becomes necessary, we could use some magic value in the reply to signal
that the server supports some non-standard stuff.

-- 
Tanu



[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux