30.05.2014 18:43, Tanu Kaskinen пишет:
On Thu, 2014-05-29 at 16:22 -0700, Jay Sorg wrote:
So we're still left to make a decision.
1 - xrdp sink and source as they are except make Alexander's
changes(everything works).
Is there an xrdp source already written? This patch only implements a
sink.
Yes, there is.
https://github.com/neutrinolabs/xrdp/blob/devel/sesman/chansrv/pulse/module-xrdp-source.c
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".
I have a draft mail on this topic, will finish and send it out later
today. It would help (to shorten the e-mail) if Jay Sorg confirms that
we indeed want to use the client sound card as the clock source.
If the esound protocol "deficiencies" (that I'm not familiar with) don't
really matter in case of XRDP, and there's not a lot of mandatory extra
cruft in the protocol that isn't necessary with XRDP, then reusing the
esound protocol sounds like a good idea.
I agree here. Also, module-esound-source would be useful anyway even
without any relation to xrdp, so that's a cheap experiment that would
leave no cruft in PulseAudio even if it fails for xrdp.
RTP is "standard", which makes it attractive, but it's not clear to me
how much practical benefit it would have. It looks like the existing RTP
modules are not very near to a working solution for XRDP (for starters,
they are designed to be attached to some other sink/source, so the
timing is driven by something else than the other end of the RTP
stream).
For me, esound is "standard" in the same sense. There are both
advantages and disadvantages in RTP as compared to esound, as well as
mere differences.
Hmm, it seems that the sink clock source in the patch is the wall clock.
This seems to defeat the whole point of a custom sink, because you could
as well load module-null-sink and record from its monitor in XRDP using
libpulse. I thought the reason why a special XRDP sink is needed is that
we want to use the client sound card as the clock source, thus avoiding
the need to resample between two clock domains.
Indeed, RTP, in any form, unconditionally forces one to use the local
clock source and add an adaptive resampler on the receiving end. A
rather complex solution, I'd say.
But I don't agree that the ability to use the existing RTP modules would
defeat the whole point of the patch. Nice sink names in pavucontrol are
definitely a benefit, and that's why it is definitely a good idea,
independently from any xrdp-related stuff, to implement a real RTP sink
and source, not needing the null-sink trickery.
--
Alexander E. Patrakov
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
