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


_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Reply via email to