Hi, > Florian Zumbiehl wrote: > > 3. Well, I don't quite understand why the generator is timed by > > gettimeofday()!? After all, that clock certainly doesn't have any > > connection with the clock that governs playback, which would be some > > DAC's crystal or the PSTN's clock, and thus usually will deviate > > from it. With VoIP, it can be somewhat difficult to get hold of > > that DAC's clock, of course, but I'd at least have expected the > > timing to be done as late as possible, and thus in particular > > independent of the source, rather than at the very source of the > > signal. > > > > Also, the timing isn't even done according to gettimeofday() while > > switching generators. > > > I haven't had time to study the generator code, so I don't really know > about the kind of internal problems you describe. However, there is one > area I can certainly comment on - the use of gettimeofday for timing. > There is a solid reason why gettimeofday needs to be used, as it is the > only source of timing for RTP and IAX streams. However, the generator
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 ... :-) > needs to dynamically choose its timing source, so it uses the hard > timing from a channel where such a thing exists. I know this is missing, > and it is unacceptable. Recently in the rxfax and txfax code CtRiX made > that code dynamically adapt between using or not using a generator, so a > generator is only used for IP streams. This is hardly a clean solution, > though, and the generator really needs to handle these cases. Well, chan_visdn uses generators for inband indications ... Florian _______________________________________________ Openpbx-dev mailing list [email protected] http://lists.openpbx.org/mailman/listinfo/openpbx-dev
