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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
