DANTE Network with X32, 2 M32's and a D400 Aviom Switch- Audio Popping

Getting the clock from the X-Dante cards is a big step in the right direction.

I don't think the cable diameter is the issue with the shells. I use direct bury cable for ruggedness in portable use. It is thick because it has double jackets, but it still fits in the ethercon shell. The jacket should be crimped in the plug.

I have found that there are plugs made for solid wires, and plugs made for stranded, and flakey connections result when cable type and plug don't match. Too many manufacturers gloss over this detail. Generally, the pass through plugs are made for stranded. Solid wires go into non-pass through plugs pretty easily. Plugs made for solid wires are often smoke colored.

Back in the ethernet dark ages, I prewired a whole rack of equipment with the wrong RJ-45s, and had flakey connections galor. I ended up redoing all of the terminations and all of the problems were solved.
 
Quite so. Nearly all RJ-45's you find for sale are solid; you have to hunt for the stranded ones, which are really only needed for building patch and drop cables, and most people don't bother to use stranded wire for that anyway.

All the stranded icecubes I've ever seen were smoke grey, though I don't think that's any kind of standard.
 
Yeah, jacket went into the plug, pulled the drain wire out and soldered it to the RJ45 shell for good luck. I'm not sure why we ended up with passthrough, but that's what Amazon sent. Everything was super stable, but at least we know where the fault lies if it comes back. I'll just gaff some tinfoil around the back of the console next time 😆
 
This has been a great thread to read through.

I'm having similar noise issues in a Dante network setup we want to use for recording, although our audio hardware is all Yamaha. The intended setup is to record individual sources directly on a Mac Mini (and possibly also on a laptop) through DVSC, while at the same time providing a mix to the video recorder. This is basically taking the existing live setup and tapping into the Dante network to record audio. Due to a lack of patchable data ports at FOH, I added a Cisco SG300-20P switch between the console and the dedicated ports to Dante Primary and Secondary switches, located in the amp room, and ran the Dante connections through that. The result was noise in all three audio recordings – the mixed feed to video, the house Mac Mini, and my personal MBP.

Some of the suggestions above are things I've already considered and/or implemented, but others have given me more things to try.

I've been using RJ45-EZ (aka pass-through) connectors for nearly 15 years, and have never had a termination issue with them. Most of that work has been done on solid core CAT cable. The only problems to crop up have been with the ports in connected hardware. One of the keys is using a really good crimp tool and making sure the cutting blade is sharp and correctly aligned. While most RJ45 connectors are designed for use with either solid or stranded cable, there are a lot on the market that are designed to work with both.

Cheers.
 
You might want to explore if you need to enable multicast for some of your flows. If you're sending audio to 3 more more devices it's advised that you enable it. Without knowing the network map it's hard to say if that's the cause or not.

And I'm not sure if I am understanding correctly, but you have the primary and secondary dante ports on the same switch? The idea with the two ports on the interface is to have two redundant but separate networks so if one fails, you can quickly jump to the backup. They aren't designed to work together over the same subnet. Though I think it does function that way if you hook it up, so I don't know that your problem is that.
 
So what's the lesson from this exciting sleigh ride of community troubleshooting?
1. Behringer's AES50 pin 1 problem?
2. Wrong connector for STP CATx?
3. Faulty termination of RJ45?
Combination of the 3?
 
You might want to explore if you need to enable multicast for some of your flows. If you're sending audio to 3 more more devices it's advised that you enable it. Without knowing the network map it's hard to say if that's the cause or not.

And I'm not sure if I am understanding correctly, but you have the primary and secondary dante ports on the same switch? The idea with the two ports on the interface is to have two redundant but separate networks so if one fails, you can quickly jump to the backup. They aren't designed to work together over the same subnet. Though I think it does function that way if you hook it up, so I don't know that your problem is that.
I did have multicast enabled for the flows.

The switch was set up with two VLANs, one for the Primary and one for the Secondary. I know this isn't best practice, but it's my understanding that it's more about the potential failure of a single piece of hardware taking down the entire Dante network, than it is about traffic issues. The Primary and Secondary are on two different subnets – each of which is using static IPs.

We went back to an earlier setup that didn't tap into the Dante flows for the individual channel recordings, and took the switch out of the signal chain, which got us back to clean recordings. The problem is, that requires using my personal MY16-AT card in the QL1, and my FocusRite 18i8 to get to my MBP (there is a FocusRite 4Pre USB going to the Mac Mini). This isn't a problem when I'm the one on hand to do the recording, but we need a set up that anyone can come in and use. The next time we are recording, I plan to use the rehearsal day to try some different configurations and see if I can get a clean signal from the Dante audio flows. One definite change will be not using the Secondary VLAN – the only device at FOH that has a Secondary port is the QL1, so that will go straight into the designated data port to the amp room. That opportunity won't be for at least another month. I'll also be looking at the switch configuration to see if there's anything I missed in the port set up.
 
The switch was set up with two VLANs, one for the Primary and one for the Secondary. I know this isn't best practice, but it's my understanding that it's more about the potential failure of a single piece of hardware taking down the entire Dante network, than it is about traffic issues. The Primary and Secondary are on two different subnets – each of which is using static IPs.

This is fine for most users. Switch failures are very rare with exception to someone accidentally unplugging one or roaching the trunk cable between switches. The most common causes of transient Dante network problems are bad cables out to endpoint devices or someone plugging something into the network that causes a major conflict because of bandwidth or a failed network port on a device that corrupts the network. I'm not wild about static IP's on Dante networks because it adds extra steps when your temporarily adding Dante devices or upgrading firmware that may blow out the IP settings, but it's not a big deal so long as you remember you have to set those statics if the system gets changed around. Dante is much more resilient and self-healing than other AV streaming protocols so the general wisdom of static-for-stability is almost always an unnecessary precaution that can create more problems than it prevents.

The result was noise in all three audio recordings – the mixed feed to video, the house Mac Mini, and my personal MBP.

What kind of noise? Blips, intermittent drop-outs, general distortion, or does it sound more like digital artifacts?

If the audio is playing continuously but there's an issue with a higher noise floor or such, it's unlikely that Dante is the cause because Dante tends to be true/false -- either it's passing audio or it isn't but the actual audio waveform isn't getting manipulated. If the EEE energy efficiency is enabled on those ports in the switch, that can create problems that will lead to blips and digital artifacts. I would probably check that and page through Yamaha's SG300 configuration guide and verify everything is set up the way Yamaha recommends.
 
The idea with the redundancy is that you would duplicate your equipment as well. In reality, it's overkill for most things. Here's the example pic from Audinate-
1609966513840.png


How you have it configured will work with what Mike's describing. I do static IP's for our network, but I have a router between us and the main network and have universal control over the addressing scheme. If you have a situation where people are BYO gear and patching in, letting the DHCP handle it might be better.

took the switch out of the signal chain, which got us back to clean recordings
That's where I think I would start. If removing that piece of gear seems to fix things, then maybe there's a setting on it that is causing you issues.

Yamaha has some pretty good resources on Dante (in some cases I found it better than Audinate's own stuff!) Here's a landing page for some of their best practices- https://usa.yamaha.com/products/contents/proaudio/docs/dante_network_design_guide/index.html
 
This is fine for most users. Switch failures are very rare with exception to someone accidentally unplugging one or roaching the trunk cable between switches. The most common causes of transient Dante network problems are bad cables out to endpoint devices or someone plugging something into the network that causes a major conflict because of bandwidth or a failed network port on a device that corrupts the network. I'm not wild about static IP's on Dante networks because it adds extra steps when your temporarily adding Dante devices or upgrading firmware that may blow out the IP settings, but it's not a big deal so long as you remember you have to set those statics if the system gets changed around. Dante is much more resilient and self-healing than other AV streaming protocols so the general wisdom of static-for-stability is almost always an unnecessary precaution that can create more problems than it prevents.



What kind of noise? Blips, intermittent drop-outs, general distortion, or does it sound more like digital artifacts?

If the audio is playing continuously but there's an issue with a higher noise floor or such, it's unlikely that Dante is the cause because Dante tends to be true/false -- either it's passing audio or it isn't but the actual audio waveform isn't getting manipulated. If the EEE energy efficiency is enabled on those ports in the switch, that can create problems that will lead to blips and digital artifacts. I would probably check that and page through Yamaha's SG300 configuration guide and verify everything is set up the way Yamaha recommends.
Definitely sounds like digital artifacts, and definitely isn't general distortion or noise floor issues.

The system was set up by the installer, in early 2019, and literally nothing was added to the Dante network until last October, when we shifted from doing in-person recitals to recording them for subscriber-accessed streaming, and I wanted a convenient way to record each individual mic separately, in addition to the mix I was creating for the video side. The first thing I had to do was track down one of the DVSC tokens that came with the QL1, Rio3224 and Rio1608 and install DVSC on the Mac Mini.

The video producer we send the recordings to described the waveform as a sudden drop in signal to 0dB, then a sharp jump back up to the program level, which conicides with a digital crackle in the audio. When I listen to the individual tracks, that noise it present in ALL of the input channels at the same time. Again, I suspect it's in the SG300, either something I missed, or an issue in the switch itself, which was taken from the electrics department spares. I will definitely check out the Yamaha site for any notes they have about it.

There's no one plugging or unplugging anything into the Dante network, and everything we are using – with the exception of the Mac Mini and my MBP – is part of the original installation. The cables from the QL1 to the Cisco switch, and from the switch to the FOH data ports, are all brand new CAT6, and when I pulled out the switch, I used the same CAT6 cables from the QL1 directly to the data ports without any trouble.
 
The idea with the redundancy is that you would duplicate your equipment as well. In reality, it's overkill for most things. Here's the example pic from Audinate-
View attachment 21359

How you have it configured will work with what Mike's describing. I do static IP's for our network, but I have a router between us and the main network and have universal control over the addressing scheme. If you have a situation where people are BYO gear and patching in, letting the DHCP handle it might be better.


That's where I think I would start. If removing that piece of gear seems to fix things, then maybe there's a setting on it that is causing you issues.

Yamaha has some pretty good resources on Dante (in some cases I found it better than Audinate's own stuff!) Here's a landing page for some of their best practices- https://usa.yamaha.com/products/contents/proaudio/docs/dante_network_design_guide/index.html
Thank you for the link. I'll definitely be looking at what Yamaha says about the SG300.

To be clear, we removed the switch AND changed the individual channel recordings to direct out from the QL1 via ADAT optical, so it could still be Dante problem related to the way I had the signal flow routed.
 
What is the Dante master clock? Are there any error messages in Dante Controller?
 
If the dropouts you're describing were a symptom of the Dante failing, you would almost certainly see something in the error log. I had an issue once with my DAW (I was using StudioOne) where it's clock or sampling rate got jacked up and it was having all kinds of issues. Recorded at like 1/3 speed or something weird. But it also had issues with dropouts and that was related to the MBP and software I was using.
 
If the dropouts you're describing were a symptom of the Dante failing, you would almost certainly see something in the error log. I had an issue once with my DAW (I was using StudioOne) where it's clock or sampling rate got jacked up and it was having all kinds of issues. Recorded at like 1/3 speed or something weird. But it also had issues with dropouts and that was related to the MBP and software I was using.
They sounded very much like the ones on the video clip you posted – but louder, and more frequent.

If they were only present on one of the recordings, I'd be looking at the computer or video deck as the problem area, but they are on all three. The common connection point was the switch, so we went back to a setup that eliminated it, and had clean recordings. I did change the recording path on my MBP to an external Seagate HDD (7200 RPM), and have asked for an external SSD for the in-house Mac Mini.

The Yamaha site has been helpful in pointing to a couple of switch setup things I may have missed. I'm back in next week, but will be using a different setup for the projects over the next month. We do need the ease of a Dante setup, so the SG300 will get reconfigured with the information from Yamaha, and I'll have my personal D-Link DGS1210 as a backup. Plan C is a MOTU828 to get playback from a Mac Trash Can to the QL1.
 
Teerence - I think the issue is how Dante handles distribution of clock via the network. The switch is not passing clock traffic correctly; this is likely a configuration issue. Clocking is the only thing common to all devices. You should see clock errors in Dante Controller.

Edit PS: If you restore the switch, in Controller make the DVSC your master Dante clock and have the surface/Rio sync to it. Does it work?
 
Teerence - I think the issue is how Dante handles distribution of clock via the network. The switch is not passing clock traffic correctly; this is likely a configuration issue. Clocking is the only thing common to all devices. You should see clock errors in Dante Controller.

Edit PS: If you restore the switch, in Controller make the DVSC your master Dante clock and have the surface/Rio sync to it. Does it work?
From material on the Yamaha site about switch setup, I've come to the same conclusion that it's something I did, or didn't do, in creating the VLANs. It's likely to be the setting in the ports connecting the main Dante switches in the rack room to the SG300. That will get looked at when I'm back in the building next week, although the Dante setup for the next recording project will be quite different.

DVSC cannot be the clock master in a Dante network. Via can be, but it's really not recommended. Ideally the master clock is a Dante-enabled device that is always present on the network. In our case, that means one of the components in the AV rack room, because the QL1 and Mac Mini are only on when the space they are intended for is in use. When the network was set up no master clock was designated; I set it as the Rio3224 because it's always on and will be used anytime we're using the QL1. The other options were the RF mic receivers or the 70V amps – everything else that gets connected to the Dante network is used in temporary setups and not always present.

I do have Dante Level 3 certification, but the "IT" side of networking is my weak point.
 
[...] I'm not wild about static IP's on Dante networks because it adds extra steps when your temporarily adding Dante devices or upgrading firmware that may blow out the IP settings, but it's not a big deal so long as you remember you have to set those statics if the system gets changed around. Dante is much more resilient and self-healing than other AV streaming protocols so the general wisdom of static-for-stability is almost always an unnecessary precaution that can create more problems than it prevents.

No reason you can't combine them, is there?

Put your fixed devices on static IPs, and leave a DHCP server enabled on the subnet carefully set not to hand out those static IPs?
 
No reason you can't combine them, is there? Put your fixed devices on static IPs, and leave a DHCP server enabled on the subnet carefully set not to hand out those static IPs?

There's no compelling reason to spend any time on statics. You can combine them in a reserved area of the subnet and cordon your DHCP range in the other part of that subnet but in my experience it just creates more problems. Somebody upgrades firmware or factory resets a device and now you have to log into the system with Dante Controller or that manufacturer's special app to set the statics.

Part of the reason statics became popular is because it was the only surefire way to connect to a specific device. So on an AV system with a lot of different devices getting controlled, it was more reliable to use statics because hostnames were unreliable and if the system had a hard reboot and all your DHCP addresses changed, you'd have a control system that couldn't control anything. Dante was built to be idiot proof though and work out of the box without special sauce configurations though -- so IP addresses basically get ignored. Dante subscriptions are all based on device and channel names. If your system is recovering from a hard reset, it's *possible* your system will come back online a little faster with statics than with DHCP -- because DHCP means that the router has to reboot first and do it's thing -- but if you're using autonegotiation without DHCP it'll come back online and transport audio about as fast as if you used statics.

My primary issue with statics has been that people forget about them. I've installed Dante systems with them before. Then I disappear and we turn the system over to the owner. 6 months goes by, they have a problem with a Lake LM-44 processor. Tech support tells them to factory reset. They factory reset, and now they've got 2-3 problems: 1) It was a redundant network and the LM-44's default to daisy-chained -- it kills your entire network -- you have to disconnect them in order to connect so you can configure them for redundant, 2) you have to use Lake's special software to change network settings, 3) you have to reconfigure the IP settings. I've also seen people who wanted to use Yamaha's Stagemix app try and stick some Best Buy WAP bridged between the consoles control port and the Dante networks, and now you could suddenly have a DHCP source you didn't plan on that could cause problems. If it's the only DHCP source on the Dante network and nothing is configured for statics, not so much a problem. If there are other DHCP sources or you have statics on some devices, now you have a problem. This gets even more interesting when someone tries to bridge their Dante/Control network with their ETCNet ports so they can use the StageMix app and RFR app on the same WiFi SSID. Suddenly you're in the middle of a tech rehearsal and everything starts to go haywire.

Other problems have been replacing or adding gear. 3-4 years after it's installed, nobody remembers there are statics and they spend several hours troubleshooting why their new piece of equipment doesn't talk to their existing equipment.

IMO, statics have long been a crutch for control/streaming systems because hostnames were unreliable. Dante was built with bulletproof hostnames and channel subscription naming. In almost all cases, that crutch of using statics has become irrelevant.
 
Last edited:
There's no compelling reason to spend any time on statics. You can combine them in a reserved area of the subnet and cordon your DHCP range in the other part of that subnet . . .
Everything in your reply is valid and makes sense, but the Dante network I'm dealing with doesn't have a DHCP server, so everything has to be either static or self-assigning.

For whatever reason, the designer or installer (more likely) set it up as static. Once I figured that out it was a simple matter of assigning the Mac Mini (in-house) and MacBook Pro (mine) IP addresses higher than the existing addresses. There were same gaps in the addresses shown by Dante Controller, but I avoided using them because there are a number of Dante devices that are rarely connected, and I assume they have been given those IPs. At the moment, the entire Dante network is physically separate from the ETCNet, control net, and – most importantly – the building IT infrastructure. There are designated Primary and Secondary Dante data ports at FOH, and in at least two of the floor pockets at the stage.

Other than within the performance space we're currently using for recording, there's only one point in the building where data ports have been connected to the Dante Primary and Secondary switches in the AV rack room, and those ports have devices connected so are very unlikely to have anyone messing with them. The education and outreach department has a camera setup they share with IT – it's a security camera and a small rack. When E&O has it, the camera records directly to a Denon unit in the rack. IT uses it as the security camera for the performance space, and takes the room mic signal, through Dante, and adds it to the video in a closed-circuit feed. There is a dedicated data port at FOH for its Dante connection. One of my ideas when we added the switch at FOH was that IT could simply plug the camera into the Primary VLAN, freeing up a data line to the AV rack, and a port in the main Dante Primary switch.
 

Users who are viewing this thread

Back