[gspydellParticipant]

If you are adding features I think a good one would be a power ‘on’ and ‘off’ with feedback from the console. Being able to write simple macros and deliver them to the console via TCP/IP is invaluable!… puts A&H in a real good place compared to the competition.

Thanks

[gspydellParticipant]

I was using a Media Matrix to control the GLD-80, but I forgot that when creating macros in NWare that you use ‘#’ instead of ‘x’… like normal hex.

[gspydellParticipant]

never mind.

[gspydellParticipant]

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!

[gspydellParticipant]

Allen&Heath has cases for the GLD-80. You can get them with or without a dog-house.

[gspydellParticipant]

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!

[Author]

Posts