On Wed, Feb 20, 2008 at 09:24:22AM -0800, Erich Boleyn wrote: > A bigger question is, then: What is the whole point of RTP? If you are > multicasting to multiple receivers without resampling, then there is > a bufferring problem which will guarantee drop-outs or gaps. I'd guess the occasional glitch isn't so annoying as to render RTP completely useless. > Is this in the plans to be fixed? (or am I basically volunteering... ;-) I have already pasted this link earlier: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2008-February/001354.html Last time, when I still thought module-rtp-recv does adaptive resampling, I interpreted Lennart's comment to mean that rtp would become as good solution as module-combine + module-tunnel-sinks (in syncing sense). Now I think it means that the clock drift elimination will eventually be copied from module-combine to module-rtp-recv - the latency difference problem would remain unsolved, but that may be a minor problem anyway. > FWIW, I noticed the other thread "Controlling where module-rtp-send > sends multicast packets?" which is talking about the use of > module-combine and tunnelling, but I have a many-to-many situation > and without a central "owner" of audio it seems a bit weird to do it > the other way. I think that solution can be used in your case as well, hacking together a centralized control thingie would just be somewhat trickier, I believe. Every sending machine would have as many tunnel-sinks as there are receiving machines. There would be one module-combine instance per stream (I guess that in your case this means one per sending machine). -- Tanu Kaskinen
