Does this product exist?

[Rob Timmerman]

Re: Does this product exist?

NO NO NO!!! It doesn't matter if you are using CobraNet or Dante, DO NOT "DAISY-CHAIN" your network!!! Think "STAR" instead...

The problem is that when you link too many network switches in a chain, the forwarding delay from one end to the other becomes too unstable.

Of course, we all know that Dante requires at least a Gigabit network, and you are limited to about 6-7 network switch hops.

CobraNet, on the other hand, with a old-school 10/100 network is also limited to about 6 network switch hops. However using a current technology Gigabit backbone in your network, you should be able to do several more than that.

Regardless, you need to remember to build your network in a star configuration, not a daisy-chain!

The network latency besomes unstable? Or you just have a variable latency depending on which points on the network you measure between?

 

[Chris Clark]

Re: Does this product exist?

According to the CobraNet data, if I'm remembering correctly it can support up to 6 "hops" for any bundle, with increased latency for each hop. This starts becoming more of an issue because of the way CNet clocks things, if the slaves can't get an accurate (consistent) lock on the master's clock they'll stop outputting audio regardless of whether they're actually still receiving data. This is another place where extra hops come into play because with each hop is another point for increasing margins of error in the sync clock...

In other words, if you're using a true single star topology, each and every device has the same number of hops because they're all running through the same switch. As you start daisy chaining switches together the devices on the second switch will obviously have a longer latency than the first switch (I don't remember if Cobranet will try to compensate the earlier devices or not). As you add more switches in into a tree topology this is when things start getting trickier because of the added latency. As packets start getting more spread out among the tree and with higher hop counts, that's when you start running into the issue of clock stability and losing audio.

At least that was my understanding of the situation from everything I've read on Cobranet (combined with my previous CCNA classes from about 8 years ago)... Not sure how Dante feels with the whole situation but it would stand to reason that there may be similar problems.

 

[Josh Millward]

Re: Does this product exist?

According to the CobraNet data, if I'm remembering correctly it can support up to 6 "hops" for any bundle, with increased latency for each hop. This starts becoming more of an issue because of the way CNet clocks things, if the slaves can't get an accurate (consistent) lock on the master's clock they'll stop outputting audio regardless of whether they're actually still receiving data. This is another place where extra hops come into play because with each hop is another point for increasing margins of error in the sync clock...

In other words, if you're using a true single star topology, each and every device has the same number of hops because they're all running through the same switch. As you start daisy chaining switches together the devices on the second switch will obviously have a longer latency than the first switch (I don't remember if Cobranet will try to compensate the earlier devices or not). As you add more switches in into a tree topology this is when things start getting trickier because of the added latency. As packets start getting more spread out among the tree and with higher hop counts, that's when you start running into the issue of clock stability and losing audio.

At least that was my understanding of the situation from everything I've read on Cobranet (combined with my previous CCNA classes from about 8 years ago)... Not sure how Dante feels with the whole situation but it would stand to reason that there may be similar problems.

Yes, that is pretty much exactly correct.

One needs to remember that an Ethernet network, is by definition a non-synchronized, best effort medium. The fact that we can even make such a medium pass real time audio at all is impressive.

Each additional network switch that you add to a network will increase the forwarding delay to the endpoints that are connected to it, when measured from a different endpoint connected to a different network switch. If you cascade many network switches in series, the forwarding delay from one end of the string to the other will result in too much variation. This variation is where the problems come from. Everyone understands by now that you need to have a steady and consistent clock to allow the digital audio to work correctly. In a networked audio system you do need to distribute that clock signal across the network and if it shows up early and late often enough, the device will just become confused and quit transmitting audio. If you are looking at the health of the devices with manufacturer provided software you may see error messages that will tell you that there is too much variation in the clocking information (beat packets... in CobraNet lingo, you may experience a "beat flood" condition).

So, this problem will depend a great deal on the forwarding delay of the network switches that are in use. Using high speed network switches with Gigabit links between them is a great way to minimize these problems, even if the endpoint links are 100Mb.