28.05.2014 10:53, Alexander E. Patrakov ?????: > 28.05.2014 02:56, Jay Sorg wrote: >> Hi Alexander, >> >>> One big question up-front, sorry for not asking it earlier. Why do >>> you need >>> to invent a custom protocol to communicate with xrdp, instead of >>> implementing something more standard inside XRDP? Especially since your >>> custom protocol is essentially RTP over stream socket minus sequence >>> numbers >>> & timestamps, or ESD minus auth plus an 8-byte header? >> >> I wanted to limit dependencies and keep it simple but it looks like >> that is a good idea. >> I really did not know it was there. I think you are talking about >> rtp.c and rtp.h. >> Is there already a RTP implementation over Unix Domain Sockets? > > Unfortunately, no. All that exists is about multicast IPv4 or IPv6, and > there even seems to be no way to suppress Session Announcement Protocol > messages. > >> If we switch to this, many of your other comments are NA so lets just >> address this one first. > > Well, a native unicast RTP sink implementation that takes the "target" > parameter would be welcome. That's a lot of work, though. > > If you want something quick-and-dirty, with all the AV-sync issues > inherent in your custom protocol due to lack of timestamps or other > latency indicators on the wire, and can wait until June 6, I can help > you add ESD protocol support in XRDP. This way, not a single line of > PulseAudio source code would need to be changed. > I have to correct myself. The ESD protocol does have server-internal latency reported. It doesn't report latency between the server and the client, but in our case it is determined solely by the amount of buffered data in the socket buffers, which PulseAudio already knows. So, it only remains to add support for three protocol elements (auth, playing stream, reporting latency) inside xrdp, which should be easy, as you have already done 80% of the work by implementing your custom protocol. -- Alexander E. Patrakov
