Florian Zumbiehl wrote: > Well, that's what I meant by "With VoIP, it can be somewhat difficult to > get hold of that DAC's clock, [...]". However, I'd argue that > gettimeofday() (alone) is not the only possibility, but rather the > timing of incoming packets usually is likely to be derived from the same > clock that also drives the DAC, so that could be used for timing > outgoing packets on VoIP connections, too. Even though a kind of PLL > between the incoming packets and the transmission scheduler probably > would be sensible then, so as to reduce jitter and to ensure > uninterrupted transmission in case silence suppression kicks in or > something. > > And then there is RTCP, of course ... :-) > The incoming timing is pretty much useless for VoIP, for a couple of reasons.
First, in an openpbx to openpbx connection, there is nothing to get things started if you just rely on the other end. Also, it would only work if the packet rate is the same from both ends. Most commonly, that is the case. Don't expect it to be true at all times, though. Second, VoIP channels stop and start with VAD, and other flow control schemes. Also, jitter would demand a pretty long settling time for a PLL, so I doubt such a thing could work. Also, if both ends used that kind of PLL scheme they could hunt around trying to track each other. Something might be possible, but it seems like a research topic. Having had no time to do the research we currently send from a local clock, which does at least get things functional. Regards, Steve _______________________________________________ Openpbx-dev mailing list [email protected] http://lists.openpbx.org/mailman/listinfo/openpbx-dev
