Clocking over GigaAce Card

Forums Forums dLive Forums dLive feature suggestions Clocking over GigaAce Card

This topic contains 1 reply, has 2 voices, and was last updated by Profile photo of Nicola A&H Nicola A&H 10 months, 4 weeks ago.

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #87466

    Hey folks!

    Just installed a GigaAce card to add redundant connection in a c2500 surface connected to a DM48. Given the documentation on the card, you would have thought that you should be able use it as the primary/secondary connection between mixrack and surface *and* still pass local audio while using it for clock. It looks like that’s not the case.

    Am I missing something? Or would the proper implementation in this case be to set WordClock port to “in” on the c2500, then run wordclock cable between the dm48 and c2500 surface?

    …if so, that seems kind of stupid, and I would like to formally request that port4 slot be capable of being a clock source for the c2500 via GigaAce i/o card in a future release.

    For now I’ve just run GigaAce A output from DM48 to the native GigaAce port on the c2500, and B to the i/o card B. The bummer is, that if A ever goes down, we lose local audio i/o on the c2500, but we still maintain control @ surface. (Until I get that wordclock run going.)

    #87490
    Profile photo of Nicola A&H
    Nicola A&H
    Keymaster

    Hi ThatComplicatedMidiGuy,

    We don’t support connection of a Surface to a MixRack via a gigaACE card in the Surface. And we don’t support redundant connection to a C Class Surface.

    The problem is not so much clocking (in fact the Surface always relies on the MixRack clock, you can only choose sync options for the MixRack) but the fact that the built-in gigaACE port has all local I/O and PAFL pre-routed, while the I/O Port hasn’t. Also the Surface I/O Port audio is simply tunnelled over the built-in gigaACE to/from the rack, to conveniently position an interface card at the mixing position, but to all intents and purposes it’s an interface into / out of the dLive MixRack. It was not designed for the application you are after.

    The control redundancy in the setup you described is simply because the ‘control network bridge’ is tunnelling the same TCP control data as the built-in gigaACE port, but the MixRack is discarding this data on link B if link A is active (otherwise you would have an IP routing loop). Sorry to disappoint but it’s not a redundant audio connection. We try to be clear in our communication that C Class = no redundancy. If any of our literature suggested the opposite, please let us know.

Viewing 2 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic.