Using GLD as monitor desk- DANTE speed?

Forums Forums GLD Forums Archived GLD Discussions Using GLD as monitor desk- DANTE speed?

This topic contains 8 replies, has 5 voices, and was last updated by Profile photo of ddff_lv ddff_lv 8 years, 7 months ago.

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #23293
    Profile photo of clarocque
    clarocque
    Participant

    I have a IDR48 and T112 I use for FOH and recording. I am looking in to getting a GLD for a backup recording desk (larger shows) and as Monitor desk when doing FOH stuff.

    The DANTE works great for recording but how will the latency be when running from the FOH IDR48 to the GLD80?

    Will the latency be noticeable or create a problem?

    Thanks

    T112, iDR48, M-DANTE, PL10, MixPad, Editor
    MacBook Pro, Mac Mini
    Lion/Logic Pro
    All latest versions/firmware

    #31383
    Profile photo of Rexeltw
    Rexeltw
    Participant

    We use DANTE for both monitor splits & to send to our Lab amp’s. Never noticed any appreciable problem with latency effects but I’m sure someone will tell me that the base delay is equivalent to moving the PA 2 metres forwards. Then again I doubt they own or use the kit in question [:D]

    PS this is on the iLive systems not GLD’s but as the card is the same…

    .

    Just remember kids no matter how good your mixing is you can’t polish a turd…

    #31390
    Profile photo of clarocque
    clarocque
    Participant

    Thanks for your input….

    T112, iDR48, M-DANTE, PL10, MixPad, Editor
    MacBook Pro, Mac Mini
    Lion/Logic Pro
    All latest versions/firmware

    #31334
    Profile photo of papromike
    papromike
    Participant

    You will not notice any latency between Dante devices, its less than 100 microseconds.

    We have networked upwards of 9 total consoles on the network with laptops in multiple spots, recording on multiple Daws and no issues at all.

    Get yourself a good gigabit switch (I like the Cisco rack mount ones) and you can broadcast that signal where ever you want.

    Vice President of Sales
    Allen & Heath USA

    #31528
    Profile photo of gspydell
    gspydell
    Participant

    Dante is a very useful protocol, but to ensure its reliability make sure to always deploy with proper TCP/IP networking architectures to minimize errors within the network.

    Dante is built, entirely, around gigabit technology, so make sure that all networking gear is at a minimum gigabit. We have a rule when it comes to Dante distribution. If you are planning on running under x32 channels of i/o on a discrete Dante/audio network you ‘can’ get by with an un-managed gigabit switch. However, if you are planning on more than x32 channels of i/o or running other data traffic on your network you ‘should’ upgrade to a managed gigabit switch. Dante is essentially VoIP on steroids, so you will need switches that have QoS (specifically, Diffserv ‘DCSP’ with strict priority). The ‘smarter’ your network the more reliable your audio transport becomes. Also, the smarter your network becomes then the faster you can run it. It is not suggested trying to run Dante at a low latency in an un-managed network (lessons learned from CobraNet).

    Make sure you try and maintain a ‘star’ network topology. It may seem logical to make the console your Dante ‘Grandmaster’, but this is not necessarily the best clock for the network. Make sure to always pick a grandmaster that is somewhat centralized within the network. A console is usually located on a branch of the network… and may even be located behind two or three switches (note: each switch adds latency to the packets). The grandmaster sends out a pulse that must penetrate the entire network… the more complex your network structure the harder it is for the ‘pulse packets’ from the grandmaster to reach every Dante client within relative time. Ethernet clocking schemes are not the same as clocking like Wordclock. I see this a lot within lab racks of PLMs. Just because each Lab PLM has an internal switch does mean that one should connect their PLM amps in series. For best performance one should always have a network switch in the rack and connect each amp to a port on the switch. Then there is an uplink from each rack to a main network switch.

    Using fiber is always best!

    Have fun!

    #31568
    Profile photo of ddff_lv
    ddff_lv
    Participant

    gspydell,

    Could you be more specific about advantages of using managed switches over unmanaged? Are you looking at network layout where Dante is combined with any other IP traffic? What exactly kind of lesson was with CobraNet? I’m kind of interested as I’m using both but totally with unmanaged switches. One of CobraNet application notes mentioned the managed switch can even do harm because it brings latency due to packet processing and buffering.
    So far I never experienced any problems, maybe my network isn’t big enough to show these problems clearly, that’s why I’m interested in experience of other users.

    ddff

    #31571
    Profile photo of gspydell
    gspydell
    Participant

    quote:


    Originally posted by ddff_lv

    gpydell,

    Could you be more specific about advantages of using managed switches over unmanaged? Are you looking at network layout where Dante is combined with any other IP traffic? What exactly kind of lesson was with CobraNet? I’m kind of interested as I’m using both but totally with unmanaged switches. One of CobraNet application notes mentioned the managed switch can even do harm because it brings latency due to packet processing and buffering.
    So far I never experienced any problems, maybe my network isn’t big enough to show these problems clearly, that’s why I’m interested in experience of other users.

    ddff


    Absolutely. NOTE: We are discussing advantages and not what ‘must’ happen in order for DANTE to work.

    An unmanaged switch (or router) will not prioritize the traffic, where a managed switch gives you the option to prioritize traffic (the degree of management is based on which OSI layer the switch can manage up to).

    Each ‘Dante’ ethernet packet is not the same; some packets will contain audio information, some will be carrying ‘clocking’ information, and some will be data (i.e. accessing your Dante module through a web browser and/or creating audio routing in Dante Controller).

    In an unmanaged switch each packet gets the same level of priority… what we call ‘best effort’.

    In a managed switch that allows for QoS and specific features like DSCP/Diffserv (with ‘strict’ priorities) the switch is then able to differentiate between the ethernet headers and prioritize the packets accordingly. All of the Dante devices are synced through the network using , what is know as, IEEE 1588… or Precision Time Protocol (PTP). In a network that supports DSCP/Diffserv the ‘timing’ packets are stamped with a HIGH priority (i.e. CS7… 0x38)… audio packets are stamped with a MEDIUM priority (i.e. EF… 0x2E). LOW priority traffic is reserved.

    What this all comes down to is a guarantee. Dante, in essence, comes from the VoIP world (Voice over IP). Sending audio over an Ethernet network is a tricky business because ‘audio’ events must show up in order… ALWAYS! That is why there will always be a fixed latency in any ‘audio over Ethernet’ protocol. However, because humans can start to detect audio latency starting around 20-30ms this delta needs to be ‘well’ within that.
    –I know this is dry, but hang in there because it will pay off–
    In normal data traffic packets are transferred using something called TCP (Transmission Control Protocol). This is part of Layer 4 of the OSI layer. What TCP gives you is a confirmation that packets have been transmitted (TX) and also received (RX). Essentially, if COMPUTER 1 is sending a packet of data to COMPUTER 2 the process goes something like this when using TCP:
    -COMPUTER 1: “COMPUTER 2 are you ready to receive DATA PACKET#1
    -COMPUTER 2: “COMPUTER 1 ready to receive DATA PACKET#1
    -COMPUTER 1: “COMPUTER 2 I am sending DATA PACKET#1… ready for DATA PACKET#2
    -COMPUTER 2: “COMPUTER 1 I received DATA PACKET#1; ready for DATA PACKET#2
    ….. and so on and so on….
    You can see that this guarantees that the data will show up. If Computer 2 didn’t receive the data packet is would simply ask for it again. But, where this is great for guaranteeing that the data shows up it takes a long time and there is added latency.

    To work around this protocols like VoIP, DANTE, AVB, ect. do not use TCP transmission they use, what is called, UDP (User Datagram Protocol). In this process there is no confirmation that packets were received (RX) by the receiving client.

    Users tend to neglect digital clocking in digital audio, but it is extremely important. Managed switches are ensuring that even if traffic gets really bad it is going to let the clocking through and then the audio.

    This also answers your question about CobraNet. A huge difference in clocking between CobraNet and Dante is that when a Dante device looses the ‘Grand Master’ it makes it up until ‘sync’ is restored. When CobraNet losses the ‘Conductor’ it tends to freak out… in one case it resulted in a BOOM that was equivalent to someone shooting a shotgun off in a room. Also, CobraNet is not a ‘smart’ protocol like DANTE. Your spot on for using unmanaged switches for CobraNet… using managed switches for CobraNet usually results in many issues. Where we (my company) are using $1k-$2k managed switches for DANTE we are also using $70-$150 Netgear switches for CobraNet.

    —- All of that being said —-
    Will you get problems when running under x32i/o on an isolated 1GB DANTE network- NO… there is not enough traffic there to bog down a GB switch.

    I like this forum!

    #31597
    Profile photo of clarocque
    clarocque
    Participant

    I have been using a cheap NetGear Gig switch to record 64 channels all summer and so far has been fine using the switch to split the signal to 2 computers. Some of the recordings ran for 4+ hours without stopping.

    I don’t know if I am just lucky or because DANTE is the only thing on that network, I was under the impression there is no need for a managed switch for a single purpose network.

    T112, iDR48 w/M-DANTE, PL10, MixPad, Editor
    GLD-80 w/M-DANTE, GLD-AR2412, GLD-AR84 (2)
    MacBook Pro, Mac Mini
    Lion/Logic Pro/PT10
    All latest versions/firmware

    #31602
    Profile photo of ddff_lv
    ddff_lv
    Participant

    I’ve been reading misc articles about QoS in audio networks and my conclusion this starts to get important in complex network setups- with more than one switch involved.
    Interesting theory though and it’ important to see that things aren’ so straight forward as we might think.

    ddff

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

The forum ‘Archived GLD Discussions’ is closed to new topics and replies.