Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Kieran Walsh]

This is using Windows Vista Professional 32-Bit on a Dell Latitude D830.

For the avoidance of doubt - Audinate have never supported Windows Vista. Some of the symptoms you describe are the very reasons why we do not support Vista.

For the purposes of transparency I would agree that very large improvements have been made to the underlying discovery mechanisms - these are the bits that previously responded slowly/ got stuck.

I am trying to get Mark to the position of the vast majority of users who see absolutely no issues as he has described. it is my expectation that we will find whatever is causing this if the will is there to persevere.

let me make this abundantly clear :

Your expectation should be that everything works in Dante controller if you are running a supported Operating System, and if your network is not being compromised by settings that make the passing of data challenging.

Checking through this In a methodical way will turn up what is causing this. Like anyone I have my prejudices, I do have several possible lines of enquiry to look at from this point - when we have some answers to previous questions it should become clearer.

[Rob Spence]

There is a (deliberate) mistake in this picture

The Wifi is connected to the same network as the Wired...

Dante controller 3.5 now helpfully paints the devices red and gives the message shown. (I am assuming this is not happening in your network)

Why is this a mistake?

I have typically 2 Dante devices on my network - a mixer and a MacBook Pro ( ok, on the LS9 I have 3).  I have a router with wifi. I connect the two Dante devices and the console network port. Static address for the mixer and DHCP on all else.
I access the mixer with my ipad via wifi. I don't have a problem. I understand that if I had lots of devices, adding the wifi traffic might be an issue.



Sent from my iPad using Tapatalk HD

[Kieran Walsh]

... Take 4... and we make reasonable demands of networks!

I say this because I tried twice to post using handheld cellular devices... and gave up (responses too wordy). Take 3 was on this laptop on a cellular data connection... I am currently on a train heading to the airport to go to Pro Light and Sound in Frankfurt. Got the laptop out an am tethered through cell phone... hopefully no more tunnels!

Rob - Thanks for posting this- it nicely shows how we can go through one of these networks in a step by step manner.

I have drawn a slight variation on your network setup to illustrate why my network was a mistake and yours isn't.

First - lets look at a physical view of what is going on- Cables and wireless- we call this layer 1.

[Kieran Walsh]

Next I have indicated where the MAC addresses are in this setup.

A MAC address is an unique hardware address that exists on a network interface. Switches connect devices by switching frames between MAC addresses.

Simply put- a Layer 2 frame has a source MAC address (sender) and a Destination MAC address (the hardware address of the interface that it is going to.

When the frame gets to the switch, the switch maintains a MAC address table. This tells the switch which Mac address is connected to which of its ports.

[Kieran Walsh]

Lets look in detail at what happens when we transfer data from one point to another on a network.

First we want to make physical connections, so we are interested in the physical layer:

[Kieran Walsh]

As we showed with the specific example each of these devices has a MAC address at each port:

As shown

[Kieran Walsh]

Lets "Make up" some MAC addresses for our devices.

The first 3 Hex "pairs" of a MAC address are used to identify the manufacturer...

Lets pretend all this equipment was made by Audinate.

The information could be shown in a table like this:

Device 1
Copper Port 01:DC:C1:01:01:01
Wireless Device 01:DC:C1:01:01:02
Device 2
Copper Port 01:DC:C1:01:01:03
Wireless Device 01:DC:C1:01:01:04
Switch
Copper Port 1 01:DC:C1:01:01:05
Copper Port 2 01:DC:C1:01:01:06
Copper Port 3 01:DC:C1:01:01:07
Copper Port 4 01:DC:C1:01:01:08
Wireless Access point
Copper Port 01:DC:C1:01:01:09
Wireless Device 01:DC:C1:01:01:10

[Kieran Walsh]

At Layer 1 I could put an electrical signal down a cable - whatever was plugged into that cable at the other end would receive that electrical signal - even if the receiver didn't understand, or was uninterested in the message being sent it would receive that message.

This is why networks exist. At Layer 2 we begin to abstract away from purely physical connections.

For example at Layer 2 I can send a message from device A to Device B - It might look Like this

Source MAC: 01:DC:C1:01:01:01
Destination MAC: 01:DC:C1:01:01:03
<message>

I can send this through the switch...

Lets look at what the switch does...

First- Q. We are only interested in the destination, why do we send the source, the sender surely knows its own address???

A. The Switch uses this to popultate what is known as a MAC Address Table
consider the following Diagram: NB I have decluttered down everything that we are not interested in at the moment

[Kieran Walsh]

The first time I send a message from device 1 The MAC address Table of the switch "pounces"

I really don't know about the international scope of this analogy - hopefully you'll understand why in a second.

In the UK where I live we have some individuals who participate in a hobby called trainspotting.
These individuals congregate at the end of Railway station platforms and log the numbers of locomotives that they have "spotted" in a book.

A switch is like a network trainspotter.

When the switch sees a message from a MAC address it dilligently logs it to its MAC address table, along with the port that it came in on. In this way it very quickly builds up a map of which port is connected to which device.

Consequently, when a message destined for a specific MAC address comes into the switch, it has a probability of knowing which port to forward the message through proportional to the amount of time it was switched on (the probability that the "destination" has said something is higher the more time passes).

However if the switch does not know which port the destination device is connected to, it simply "floods" the message - this means it forwards a copy out of every port, apart from the port the message originated on. The assumption being that at some point the destination could well signal back that it has received the message, and then with its silence broken, its connection will be revealed. In reality, this temporary flooding behaviour of a switch will only last a few milliseconds maximum.

The MAC Address table in our example may look like:

01:DC:C1:01:01:01 Connected to port 1 (internal MAC 01:DC:C1:01:01:05)
01:DC:C1:01:01:03 Connected to port 2 (internal MAC 01:DC:C1:01:01:06)

NB Switches will not "show" the internal MAC addresses to the outside world, but these are used by the switch to fulfil its function.

[Kieran Walsh]

"Great" I hear you all say... we've got a message from point A to B... thats networking done, lets head off down to the pub!

And indeed if you want a point to point solution there is not much more that you need to do to make this happen...

Now for a bit of "how we do stuff" - others may not agree... there are different approaches. What I say is one way of looking at it. Of course I think it makes sense. I do respect those who don't agree- after all that is why and how we develop overall better solutions (we as in the human race in that last sentence).

The following is very general, and is trying to give a sense of why... I just read a 500 page book that covers only part of this...

Writing software in a Unix based environment (Unix is the granddad of Mac OSX and Linux inter alia) devices are treated as files. If I want to send a message from my application, all I need do is "save" that file to the network device... OK so we would be used to the file sticking on a disk or USB stick or something, however if I save it to the Network device, that network device will deal with sending that data.

We have established that the network interfaces have MAC addresses- so we could (in theory) have a "file" that is the device directly at the MAC address.

In general software programmers don't like to do this.

If anyone has tried to save to the same file from two places at once, you will have a good idea why this could be considered a limited approach.

If only one application was using the network port, or even at a stretch one like minded collection of manufacturers agreed how they would use that port, and developed a set of ways to deal with this... then we would still be some way behind the mainstream.

The "mainstream" way to use network ports is to use a piece of code like socks (Windows has Winsock). Socks allows the programmer to "ask it" to deal with data that the application being made by the programmer spits out. Because the vast majority of programmers have no desire to rebuild an already perfectly working (and free) piece of software that they have likely spent many months if not years of their lives mastering... all I am saying is that a lot of very skilled people were involved in solving this "problem"

One cool thing about this is that it allows the programmer to get on and use Layer 3.

A lot of the appeal of Layer 3 is that you have IP addresses... in and of itself, at a first glance it would appear to be not that exciting.

IP addresses and Layer 3
So as with Layer 2 we gained the ability to target specific pieces of hardware, which meant that we didn't have to worry so much about data going to locations where is was useless, layer 3 tidies up some essential aspects of what keeps this running. I mentioned flooding - when the switch just splurges out data if it doesn't know where the destination is. This is fine on a small scale - but on a global scale... its really bad. We call the area where the flooding can be picked up the "broadcast domain" Routers (which are layer 3 devices) segment the broadcast domain.

So from below - we get tidier, more scalable networks. From above, we get some cool features of IP addresses too. Its likely that many people will know that internet explorer uses port 80 by default... what does this actually mean?

Well it means that if I want to follow convention - when I write an application, I should be careful telling it to "write to" port 80. in fact there are a lot of "reserved" ports these are documented. Now something like socks does not stop me using those ports - if I decided everyone in the world was wrong, and I wanted to ignore them, I would use any port number I felt like - not really the behaviour of a "good citizen" especially as there are 16 bits worth of sockets for every single IP address!

oops did I say sockets? yes - Socket is what generally application people use- they "map" to ports- sockets are also used for inter-application communication... the communication doesn't have to use cat 5 and an RJ45 jack by layer 3 we are completely abstract!

Now I can write data to an unreserved socket/port and socks can deal with holding that data in a file, and then shoving it through the device when there is some availability.

As the vast majority of applications dump their data through something like socks, then it is an effective way of sharing the resource that is the network port, and allowing all manner of applications access to the port - this allows me to use Dante Virtual Soundcard, whilst I check my email.... or indeed use Dante Virtual Soundcard as the interface to Skype from my Dante enabled wireless microphones and speakers (if you havn't tried this trick you should... its very cool).

Now of course you could go to a lot of time and effort and build direct access in through layer 2 and then work out some smart way to pretend to the other applications that nothing had been messed with (the OS might have something to say about that) ... after all its engineering, everything is possible.

[ProSoundWeb Community]