[asterisk-dev] M9645: provide zaptel master timing to spans

[Matthew Fredrickson]

On May 2, 2007, at 2:19 PM, Oron Peled wrote:

> On Wednesday, 2 בMay 2007 20:43, Matthew Fredrickson wrote:
>> On May 2, 2007, at 11:23 AM, Andrew Kohlsmith wrote:
>>> When you get an interrupt, couldn't you simply chain through their
>>> respective handlers?  I don't see any reason why not.
>>
>> Because if you're dealing with a DMA'd buffer, the data in the buffer
>> could be in an inconsistent state.  For example, if you ran zt_receive
>> on your buffer, and the data in the buffer hasn't changed yet, you get
>> your old data twice, because your card's timing isn't in
>> synchronization with the master card's timing.
>
> You are correct that the proposed mechanism cannot be used to
> chain interrupts directly (and it's not used in this way).
>
> However, it propagate the master card timing information to
> any interested driver and *enables* it to synchronize its clock
> (assuming the hardware was designed with this capability...)
>
> Let's take the following scenario:
>   - One Digium PRI or BRI card connected to the public phone system.
>     Obviously it is synchronized from the phone network.
>   - Some Digium FXS cards connected to internal telephones
>     and Fax machines.
>   - You would have synchronization problems between the two
>     cards resulting in sound quality problems (small ticks
>     here and there). Due to Fax sensitivity, the situation
>     may be worse (failing to Fax from PRI to FXS).
>
> The tiny proposed patch gives a hook for people that
> implement a solution (using proper hardware).
>
> It's not the perfect solution, but what are the alternatives
> to scenarios like the above?
> (without utopian adventures like a complete zaptel redesign).

I think that sounds good, and perfectly legitimate for hardware that 
supports it.  Patch is +1 from me, tzafrir :-)

I'm just concerned about the whole, daisy chain the interrupt handlers 
together idea, without the cards having any type of card level timing 
synchronization :-)  I think it's a recipe for data loss.  For updating 
a PLL on a device, this might be an interesting idea.

Matthew Fredrickson