I’m working with a network configuration for an organization that has a decent sized Dante network. The original configuration had everything in a large conference arena, and the dante equipment was connected with a $40 1Gb monoprice switch. They want to move some of their audio equipment to another conference room and bridge the audio. I analyzed the traffic and it’s about 80Mbps, so I’m thinking it’s gonna be an easy thing to just put this on their 1Gb unifi switches. I did a test connection on a single switch before I moved the equipment and all worked on one unifi switch.
Then my problems began. The final path between conference rooms is a three switch hop. Not a problem, right? The Dante spec gives specs for up to 10 switch hops. However, I’ve had problems getting an audio sync due to timing issues. It turns out that Dante uses PTP (Precision Time Protocol) to sync the audio devices. I’ve got the setup working with a few dumb switches, but I can’t get the unifi switches to work.
From what I can tell on my reading so far, a switch that truly supports PTP will adjust the timing as it passes the traffic. Well, I can assure you that the $40 monoprice switches are not doing this. PTP can be somewhat forgiving as long as devices aren’t royally screwing with the signals, evidently. What I can’t figure out is what settings I might could utilize on the unifi switches to enable the Dante to work. I’ve got a rather stupid looking workaround for now, but it’s killing me not to have a working solution with better hardware.
You are probably going to need to look into some kind of traffic shaping and priority settings based on the type of traffic or on the IP address to/from for the audio streams. Essentially a QOS like one might set up for VoIP phones.
After that, can’t help as I don’t have any of these switches.
Do you really need to go through all these hops? Just wondering if you could get the number down by installing larger switches and new cables???
Yes QOS is one of the issues. The other is that although the audio packets are sent in unicast streams, PTP is coordinated over the switch with multicast. However, IGMP snooping doesn’t appear to work correctly with the Unifi switches. (Separate discussion for later). Basically, I’ve had to disable IGMP snooping for this and a few other video solutions to work when working on unifi networks.
I actually work a lot with PTP on utility grade network switches, and they have specific options for PTP passthrough, but those are a different league of switching hardware (both price and capability). Even Cisco only offers dedicated PTP options on a subset of their full product line. But, since Dante can handle up to 10ms of delay, it’s fairly fault tolerant to different hops, as long as the link delay is not too high. I’m measuring about .3 ms delay between the unifi switches on this particular network, so I can rule out the delay issue, but I have to be able to enable QOS and prevent the unifi switches from tinkering with the multicast packets.
The hops are required due to hops between buildings and floors. I can actually eliminate the problem by moving to Cisco switches (or even the $40 monoprice switches they currently have), but I’m hopeful that I can come up with a solution with the unifi, since they are so easy to manage (and it’s what the organization already has). They would also like to start routing some of the audio to some of their office PC’s, which are on the unifi network. I have multiple incentives to get this working.
Sounds like a big project. Only thing I can say is that there are several places that sell used Cisco with lifetime warranty (and current products in same condition) but still not going to be as cheap as what is already installed.
Yep. This particular group just moved from older equipment Cisco to Unifi last year (about 8 months ago) due to the ease of management. And honestly, until this came up, they’ve had no real issues with the system. Cisco is super powerful, but the maintenance costs are much higher. I’ve got switch profiles set up for their VOIP system that enables them to move phones and make switch configuration changes a breeze. That’s not going to happen with Cisco, and although I would enjoy the money, I don’t want to put them in a position where every move of equipment requires me to remote in and adjust settings.
Keep in mind when you read the following, that my Dante knowledge is small, as is my Ubiquiti knowledge:
It seems like Dante and ViOP would be almost the same policies needed and it should be an easy thing to set up on anything that can handle ViOP devices.
I’ve looked into setting up a Dante system for our radio station, but the automation software doesn’t support Dante, they still need a physical sound card, and those cards are expensive. (ASI cards)
A little off topic, but if you’re using the same computers we did when I worked in radio, you should be able to install the virtual sound card software, and it’d work just fine. And depending on the use, there’s also Dante Via. The software appears just like a hardware card to the computer software. I’ve installed it on about 10 different machines – both windows and mac.
Continuing the OT, We are using BSI Simian, and it actually uses the sound card to play the file. It has a software method but not as stable and missing some features with segues between files. They can use the Wheatstone network or the Radio Systems network, but not Dante as of last Spring when I checked.
Hey just want to call out that IGMP snooping (also called Passive) will not help Multicast traffic at all without an IGMP Querier (also called Active), in fact it will discard all multicast traffic. When a switch has snooping enabled, it listens for devices joining a multicast group and keeps track of that in a list. The Querier (either the router, or a core switch) from time to time broadcasts the fact that it exists, and asks all the switches for their multicast client membership lists. Once a snooping switch knows the querier it can also send new memberships as they happen without waiting for the next cycle. The Querier takes the lists from all the switches and compiles it. It then sends back to each switch information about what ports should and should not be a member of each multicast group. For example, if there are only two clients on Switch A that are part of 224.254.0.1, then only those two ports and no others will receive packets bound for that group. Then if a client on Switch B joins the group, the querier will tell Switch A to also include the port connecting to Switch B in the group, and on Switch B the port connecting to the client and to Switch A will be part of the group. Without a Querier telling all the switches what to do, they will just hold onto the membership data forever and not do anything with it, meanwhile they will drop all multicast traffic because the default is that no ports are members of any group.
Unifi’s IGMP snooping and querying is complicated and messy - this is why brands like Control4 explicitly do not support Unifi. When you enable IGMP Snooping on a VLAN in Unifi, each switch will listen to see if there is a querier, and if it doesn’t hear one it will become it. This means its a race and random as to which of your switches will do it - although in the end that doesn’t affect traffic. The problem comes if you have some other device on your network being a querier, then all hell breaks loose. See this forum post for some details (and many others), I haven’t seen anything from Ubiquiti about improvements or fixes. https://community.ui.com/questions/disable-igmp-querier/14e5e153-fe9f-4e33-9af0-e0573c0d7b82
As previously mentioned, I had to disable IGMP snooping for the multicast to work on the Unifi switch.
Doing so allowed the audio to work, but introduced a periodic clicking that wasn’t previously there.
After doing more research, I discovered that the clicking was due to a checkbox that I had unchecked while figuring out the multicast issue. If you have a Dante network, at least one device has to be the master clock. But in addition to that, if that device is using it’s own internal clock (mixer or other high-end Dante card), it also needs to be configured to allow external sync. This is counter-intuitive, given that fact that it’s using it’s own clock as a driver, but after reading several informative posts from a couple of different audio manufacturers, I enabled this and the clicking went away.
I’m determined to get the IGMP snooping to work correctly, though. I think I’m going to set up a Cisco SG300 on the network to act as the IGMP querier, although it’d be nice if the pfsense box handled it. I never had to worry when all the gear was Cisco because I could manage it easily through their interface. There’s not a lot of good tutorials on getting to the cli interface of the unifi switches. I may suggest it as a video suggestion for Tom, but I doubt he’d take it on. It’d be fun to see how he would set it up and validate it with his virtual lab.
There are some hardware devices that are made to be Dante Master clocks out there, a quick google showed a few in the $2600+ price range. I would suggest going to something like this instead of using a device as the master, devices tend to get shutdown at the least opportune moment and in theory the master clock could just hang out in a switch closet. You may want to demonstrate why you need one to your boss, just set up a test event in one room, and walk over to your current master and turn it off or disconnect it. That’s normally enough to push the budget.
There some other useful tools within Dante Controller that can help weed out multicast issues:
In the Clock Status tab, see if multiple master clocks are present. This would indicate some kind of multicast blocking affecting PTP.
Audio flows are unicast by default but can be multicasted if preferred.
In “device view” in the Device Config tab, you can enable “unicast delay requests” to help narrow down the source of multicast blocking issues.
On lower right, click on colored (hopefully green) box: “Clock Status Monitor”; select device and go to “History” tab. This graph should be tight and narrow. If there is a wide range of frequency offsets this indicates multicast issues as well but you can possibly track a problem from the perspective of each device with regard to where it sits on the network topology.
…thought these may come in handy in the future, for any Dante user.
Re: clock elections:
Dante networks will automatically elect a master clock.
Any device with “Enable Synce To External” checked will win.
If no externally synced devices, any device with “Preferred Master” checked will win.
If there is a tie, the lowest MAC address wins.
If none of the above criteria is met, again the lowest MAC address will become the clock master.
Using a device as a master should not be a problem. As you say it’s obviously best to make it a device that will not have any downtime… and I feel a little warmer and fuzzier when it’s a beefier chipset like a Brooklyn II or something like that. I’ve had a network up for years without issue using a Yamaha card frame (RSio) as the master.
