28.05.2014 12:08, Jay Sorg wrote: >>> 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. > I really want something that is clean, efficient and optimal in design. Good :) but designing clean and efficient things takes time. > 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). > There can be xrdp servers with 50 users. That's 50 pulseaudio daemon > on one machine. > I'll take your advise but I hope you can understand my requirements. > I already tied so many recommendations(from pa) that just didn't cut it. Sorry for conflicting with the previous advice. > > One thing that I really think you guys should do is allow out of tree > modules build support. We would not need this discussion if you had a > clean and stable API like so many other projects. That would be nice indeed, but unfortunately at the moment there is no way to build out-of-tree modules. Just as a side note (not as a proposal): a different solution is employed by ALSA. They also don't expose the full possibly-unstable plugin API, but have an "external plugin SDK" with a stable API that allows to build limited-functionality plugins that do external I/O, and external filters. -- Alexander E. Patrakov
