[asterisk-dev] BugID 014021, Zap/DAHDI timers, internal timing and packetization

[Dan Austin]

Russell wrote:
>> I know the issue can be solved, but I am not sure it can be solved
>> in 1.4 or 1.6.0 since the fix will likely need changes to the
>> channel structure.


> It definitely sounds like you're on the right track to the fix for
> this.  Thank you for working on it!

> As far as changing ast_channel goes, we might be in luck.  I just
> deprecated a field in the ast_channel struct as a part of a bug fix.
> However, it's still there for the sake of maintaining ABI.  So, we
> actually have 80 bytes that we can use for other things if needed.  :-)

> You could change:

>    char unused_old_dtmfq[AST_MAX_EXTENSION];

> to something like:

>    union {
>       /*! This is a deprecated field of the ast_channel struct */
>       char unused_old_dtmfq[AST_MAX_EXTENSION];
>       /*! The size of the following struct must be less than or equal
>to AST_MAX_EXTENSION */
>       struct {
>          uint16_t timer_rate;
>       };
>    };

Thanks again.  I will look at that tomorrow.  I kept thinking through
the problem, while avoiding to code, to get code flow understood before
making anymore changes, and I think I have uncovered another issue.

Even with the proper timing per channel, the smoother_feed only receives
frames when the channels write function is called.  If we are feeding
20ms frames to a 30ms channel on a 30ms timer, there will be major
jitter.  I am thinking that the solution will be to fire the timer
on the current codec's framing interval.  That will mean that the
write function gets called a lot more frequently, but we can teach it
to just feed the smoother until required framing interval has been
reached, or the smoother has enough data to create a properly sized
frame/packet.

Dan