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
