Print

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

[Dave Pluke]

Static ARP entries have far more potential to cause problems than they do the potential to solve them.

Agreed.

@Kevin: Don't feel obligated to fill in every single editable field in the configuration screen.  Setting static IP address for each of your mixers makes sense, so you can create bookmarks and always know which is which.  Other than that, let autonegotiate do its thing.

If everything is connected to the LAN side of your router, UDP should communicate fine (it's all inside the firewall).

Dave
 

[Kevin Maxwell]

Jean-Pierre is exactly right,  on an active connection an ARP entry is not going to get flushed.  It just doesn't happen.

UDP is the protocol used for most real time streaming including video and Voice over IP.  I promise you the President of Melon bank would notice if a syllable was cut off the conference phone in the boardroom.   I can tell you that their VoIP Vlan is devoid of any static  ARP entries.

I  am not trying to be an arrogant douche, I have been implementing packet voice systems for 25 years (or more).  There are many things you can do to improve jitter and latency. 

Static ARP entries have far more potential to cause problems than they do the potential to solve them.

Thank you for your attempt to help me.

I am curious as to exactly why for my application that the “static ARP entries” would be a potential problem. I am trying to not be a jerk in anyway about this I just don’t learn by being told not to do something especially when the guy who wrote the program tells me to do it. This is only for using while doing Musical Theater shows.

The parts of the system are.
    An HP notebook computer running Windows 8.1

   Linksys WRT54GS WiFi Router/Switch (Playing with this to understand functionality because I had one lying around).

   At the moment 1 Midas M32 mixer, possibly more in the future. Palladium can control 3 mixers at once and a bunch of other outboard devices. I have used 2 M32 mixers controlled by Palladium for a show over Midi but now I am using OSC (to and from Palladium) for the control.

   Android phone running Mixing Station Pro. Used just to adjust ratio of front fills and delays during setup and maybe rehearsal. And general setup things. On the WAP 5Ghz that I have used (only thing connected to the Ethernet port of the M32 when doing concert work I have the SSID hidden and only devices with registered Mac address able to connect and this works great. If I actually use the Linksys for a musical I will lock the WiFi down as best as I can.

   The other Palladium user I am trying to help out is using a 21” android tablet to be able to display more of the mixer (M32 also) without having to swap layers or screens on the mixer itself.

   I have no desire to have this system in any way connected to the internet. The other user might want internet access so he can download things. I am trying to discourage him from that.   
   

My application is a VERY closed system.

Computer running Palladium and maybe also M32 edit connected via Ethernet cabling (happens to be Cat6a) to the local port of the router/switch. M32 connected to the same router/switch to another of the local ports. Android device communicating over the router/switch WiFi. For me nothing connected to the internet port.

The way I have it set now seems to be working but as I said before I don’t know if that is by luck or if it has to do with any of the settings I have done. 

These are some of the setting I have now.
The computer is 192.168.1.103
The M32 is 192.168.1.104 and the gateway is 192.168.1.1
In the Linksys WRT54GS
The routers local IP address is 192.168.1.1
In the network address server settings
Starting IP address is 192.168.1.100
Static DNS 1: 192.168.1.200 – I put this in there because I thought I would use it on the console. I don’t know what addresses in general are reserved (if any) for DHCP and what range is good to use if using Static IP addresses.
Static DNS 2: 192.168.1.104  - I added this and then the android app Mixing Station pro worked, but I don’t know if I did something else in-between that is what really made it work.
Under applications and gaming / Port range, I entered Application – Palladium, Start – 10020, End - 10024 (since Palladium uses Port 10023), Protocol – UDP,  IP Address - 192.168.1.200, and checked Enable. During testing I unchecked enable and everything still seemed to work. I don’t know if this did anything.

Maybe I should start eliminating some of these settings and see if I lose control.

Thank you for nay help you can be and let me know if you need any more information.

[Scott Holtzman]

Thank you for your attempt to help me.

I am curious as to exactly why for my application that the “static ARP entries” would be a potential problem. I am trying to not be a jerk in anyway about this I just don’t learn by being told not to do something especially when the guy who wrote the program tells me to do it. This is only for using while doing Musical Theater shows.

The parts of the system are.
    An HP notebook computer running Windows 8.1

   Linksys WRT54GS WiFi Router/Switch (Playing with this to understand functionality because I had one lying around).

   At the moment 1 Midas M32 mixer, possibly more in the future. Palladium can control 3 mixers at once and a bunch of other outboard devices. I have used 2 M32 mixers controlled by Palladium for a show over Midi but now I am using OSC (to and from Palladium) for the control.

   Android phone running Mixing Station Pro. Used just to adjust ratio of front fills and delays during setup and maybe rehearsal. And general setup things. On the WAP 5Ghz that I have used (only thing connected to the Ethernet port of the M32 when doing concert work I have the SSID hidden and only devices with registered Mac address able to connect and this works great. If I actually use the Linksys for a musical I will lock the WiFi down as best as I can.

   The other Palladium user I am trying to help out is using a 21” android tablet to be able to display more of the mixer (M32 also) without having to swap layers or screens on the mixer itself.

   I have no desire to have this system in any way connected to the internet. The other user might want internet access so he can download things. I am trying to discourage him from that.   
   

My application is a VERY closed system.

Computer running Palladium and maybe also M32 edit connected via Ethernet cabling (happens to be Cat6a) to the local port of the router/switch. M32 connected to the same router/switch to another of the local ports. Android device communicating over the router/switch WiFi. For me nothing connected to the internet port.

The way I have it set now seems to be working but as I said before I don’t know if that is by luck or if it has to do with any of the settings I have done. 

These are some of the setting I have now.
The computer is 192.168.1.103
The M32 is 192.168.1.104 and the gateway is 192.168.1.1
In the Linksys WRT54GS
The routers local IP address is 192.168.1.1
In the network address server settings
Starting IP address is 192.168.1.100
Static DNS 1: 192.168.1.200 – I put this in there because I thought I would use it on the console. I don’t know what addresses in general are reserved (if any) for DHCP and what range is good to use if using Static IP addresses.
Static DNS 2: 192.168.1.104  - I added this and then the android app Mixing Station pro worked, but I don’t know if I did something else in-between that is what really made it work.
Under applications and gaming / Port range, I entered Application – Palladium, Start – 10020, End - 10024 (since Palladium uses Port 10023), Protocol – UDP,  IP Address - 192.168.1.200, and checked Enable. During testing I unchecked enable and everything still seemed to work. I don’t know if this did anything.

Maybe I should start eliminating some of these settings and see if I lose control.

Thank you for nay help you can be and let me know if you need any more information.

Honestly you are way in left field.  Why those IP addresses in DNS?  I am sure there is no DNS resolver on an M32 so you have far more potential for an application to time on waiting on a DNS response than a MAC Fill on a "who has" broadcast.

The "gaming" port triggering is a Layer 3 construct.  Since you are only using the WRT as a bridge it isn't doing any IP routing at all.  If it was port forwarding would screw everything up because it is part of NAT.  UDP doesn't survive NAT traversal well.

The WRT is still the weakest link with the old RF chipset and no 5Ghz support.

Sure you can populate the MAC address in the ARP table but to what end?  To save a broadcast message?

[Russell Ault]

Sure you can populate the MAC address in the ARP table but to what end?  To save a broadcast message?

I helped a little with the development of the OSC version of Palladium (I was a long-time Palladium user who bought an X32 and then wrote my own MIDI-OSC interfacing software in Java to make the two talk to each other, then shared my experiences, good and bad, with Chris when the OSC version was in development). The static ARP "thing" is to solve a very specific problem: Windows XP's networking stack sucked. Like, really sucked. And Palladium was designed to be XP-compatible, so static ARP was put into the documentation.

For the curious, the problem with the XP networking stack is that it would always expire dynamic ARP table entries after a fairly short, fixed period of time, regardless of how long it had been since the entry was last used. This meant that every 10 minutes the Palladium computer would be forced to re-generate the APR entry for the console, and the computer's networking stack would drop packets until the MAC address had been looked up, and because OSC is UDP, those packets would be gone forever. In the case of Palladium, this meant cues would only half-fire (or not fire at all) once every ten minutes or so, which would cause problems that were somewhere between extremely annoying and "hearing people relieve themselves through the P.A." disastrous.

Every other operating system's IP networking stack, including Unix-like OSes and Windows Vista and up, use a more sensible system where an ARP entry is only expired if it goes unused for a period of time (I discovered this the hard way in my own MIDI-OSC translation software when parts of a cue would get dropped, but only if it had been a few minutes since the previous cue). As long you keep sending data from the computer to the console, the ARP entry will never expire, and no packets will be dropped waiting for MAC address lookups. On these platforms the easiest solution, then, is to make sure the computer is regularly sending some message or other to the console, and sending the /xremote OSC command every ~9 seconds to keep the X32 OSC subscription alive does this masterfully.

TL;DR: static ARP is vital if you're trying to use Palladium (or anything else that relies on UDP) on Windows XP, and basically worthless on any other modern platform.

-Russ

[Kevin Maxwell]

I helped a little with the development of the OSC version of Palladium (I was a long-time Palladium user who bought an X32 and then wrote my own MIDI-OSC interfacing software in Java to make the two talk to each other, then shared my experiences, good and bad, with Chris when the OSC version was in development). The static ARP "thing" is to solve a very specific problem: Windows XP's networking stack sucked. Like, really sucked. And Palladium was designed to be XP-compatible, so static ARP was put into the documentation.

For the curious, the problem with the XP networking stack is that it would always expire dynamic ARP table entries after a fairly short, fixed period of time, regardless of how long it had been since the entry was last used. This meant that every 10 minutes the Palladium computer would be forced to re-generate the APR entry for the console, and the computer's networking stack would drop packets until the MAC address had been looked up, and because OSC is UDP, those packets would be gone forever. In the case of Palladium, this meant cues would only half-fire (or not fire at all) once every ten minutes or so, which would cause problems that were somewhere between extremely annoying and "hearing people relieve themselves through the P.A." disastrous.

Every other operating system's IP networking stack, including Unix-like OSes and Windows Vista and up, use a more sensible system where an ARP entry is only expired if it goes unused for a period of time (I discovered this the hard way in my own MIDI-OSC translation software when parts of a cue would get dropped, but only if it had been a few minutes since the previous cue). As long you keep sending data from the computer to the console, the ARP entry will never expire, and no packets will be dropped waiting for MAC address lookups. On these platforms the easiest solution, then, is to make sure the computer is regularly sending some message or other to the console, and sending the /xremote OSC command every ~9 seconds to keep the X32 OSC subscription alive does this masterfully.

TL;DR: static ARP is vital if you're trying to use Palladium (or anything else that relies on UDP) on Windows XP, and basically worthless on any other modern platform.

-Russ

Russell, Thank you very much for that. And thank you for helping Chris with all of this. The ability to use OSC with Palladium and the M32 has expanded what can be done with the X/M32 platform.

When I first got into Palladium I was still using a VERY expensive and very good Notebook PC that was still running XP but the video subsystem died on it after many years of service. This is information is very good to know, so I probably don’t need to worry about the ARP table anymore since I am using a Windows 8.1 PC that is our dedicated show computer or if I needed to I can use my personal Windows 7pro64bit PC. But a fellow Palladium user that a lot of this is for so I can more knowledgably help him, I think dug up a PC with XP on it that he is using. 

[Scott Holtzman]

I helped a little with the development of the OSC version of Palladium (I was a long-time Palladium user who bought an X32 and then wrote my own MIDI-OSC interfacing software in Java to make the two talk to each other, then shared my experiences, good and bad, with Chris when the OSC version was in development). The static ARP "thing" is to solve a very specific problem: Windows XP's networking stack sucked. Like, really sucked. And Palladium was designed to be XP-compatible, so static ARP was put into the documentation.

For the curious, the problem with the XP networking stack is that it would always expire dynamic ARP table entries after a fairly short, fixed period of time, regardless of how long it had been since the entry was last used. This meant that every 10 minutes the Palladium computer would be forced to re-generate the APR entry for the console, and the computer's networking stack would drop packets until the MAC address had been looked up, and because OSC is UDP, those packets would be gone forever. In the case of Palladium, this meant cues would only half-fire (or not fire at all) once every ten minutes or so, which would cause problems that were somewhere between extremely annoying and "hearing people relieve themselves through the P.A." disastrous.

Every other operating system's IP networking stack, including Unix-like OSes and Windows Vista and up, use a more sensible system where an ARP entry is only expired if it goes unused for a period of time (I discovered this the hard way in my own MIDI-OSC translation software when parts of a cue would get dropped, but only if it had been a few minutes since the previous cue). As long you keep sending data from the computer to the console, the ARP entry will never expire, and no packets will be dropped waiting for MAC address lookups. On these platforms the easiest solution, then, is to make sure the computer is regularly sending some message or other to the console, and sending the /xremote OSC command every ~9 seconds to keep the X32 OSC subscription alive does this masterfully.

TL;DR: static ARP is vital if you're trying to use Palladium (or anything else that relies on UDP) on Windows XP, and basically worthless on any other modern platform.

-Russ

This is very interesting Russell.  I was involved with an effort to create a Java SIP softphone.   RTP is UDP and we had this issue with the socket interface in Java. 

Where you using DatagramSocket() constructor?

[Russell Ault]

This is very interesting Russell.  I was involved with an effort to create a Java SIP softphone.   RTP is UDP and we had this issue with the socket interface in Java. 

Where you using DatagramSocket() constructor?

Yep, DatagramSocket(int port, InetAddress laddr) to be specific, and just one, since the X32 OSC protocol requires that all 3rd-party connections send and receive on the same port. Had massive problems trying to run it on XP, had minor problems initially on Windows 7, and then had 100% message transmission when I made sure to send a message to the console at least once every 9 seconds. (This makes sense, given my understanding that DatagramSocket() is typically just a very thin wrapper over the OS's native networking functions.)

In theory this is partly an IPv4 problem, since IPv6 includes Neighbo(u)r Discovery as part of the base protocol, but I'm pretty sure the X32 isn't IPv6 ready, and even if it is that's not a pro-audio-focused tutorial that I'd want to write...

-Russ

[Scott Holtzman]

Yep, DatagramSocket(int port, InetAddress laddr) to be specific, and just one, since the X32 OSC protocol requires that all 3rd-party connections send and receive on the same port. Had massive problems trying to run it on XP, had minor problems initially on Windows 7, and then had 100% message transmission when I made sure to send a message to the console at least once every 9 seconds. (This makes sense, given my understanding that DatagramSocket() is typically just a very thin wrapper over the OS's native networking functions.)

In theory this is partly an IPv4 problem, since IPv6 includes Neighbo(u)r Discovery as part of the base protocol, but I'm pretty sure the X32 isn't IPv6 ready, and even if it is that's not a pro-audio-focused tutorial that I'd want to write...

-Russ

That would be a learning curve.  Here is a quick tcpdump of our proprietary IP telephony protocol.  Notice the POKE/PONG - that's UDP keepalive.  Since we also had to be concerned about surviving a significant number of routing hops the keepalive traffic is even more important as cheap firewalls don't have programmable port timeouts so they will destroy UDP sessions. 

Code: [Select]

[root@localhost ~]#
[root@localhost ~]# tcpdump port 4569 -c 50 -XX
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
20:38:21.400359 IP 192.168.2.252.iax > net-207-58-213-177.arpa.fidelityaccess.net.iax: UDP, length 14
        0x0000:  0014 f6e6 7c89 001d 72ac 2101 0800 45b8  ....|...r.!...E.
        0x0010:  002a d85a 0000 4011 3920 c0a8 02fc cf3a  .*[email protected]......:
        0x0020:  d5b1 11d9 11d9 0016 68b8 9c30 0000 0000  ........h..0....
        0x0030:  0003 0000 061e 3600                      ......6.
20:38:21.496769 IP 192.168.2.252.iax > 204.16.90.9.iax: UDP, length 30
        0x0000:  0014 f6e6 7c89 001d 72ac 2101 0800 45b8  ....|...r.!...E.
        0x0010:  003a 3049 0000 4011 5ff4 c0a8 02fc cc10  .:0I..@._.......
        0x0020:  5a09 11d9 11d9 0026 e9f5 97c5 0000 0000  Z......&........
        0x0030:  0010 0000 060d 060a 5363 6f74 745f 486f  ........Scott_Ho
        0x0040:  6d65 1302 003c 3600                      me...<6.
20:38:21.535938 IP 204.16.90.9.iax > 192.168.2.252.iax: UDP, length 65
        0x0000:  001d 72ac 2101 0014 f6e6 7c89 0800 4500  ..r.!.....|...E.
        0x0010:  005d 99f2 0000 3211 04e0 cc10 5a09 c0a8  .]....2.....Z...
        0x0020:  02fc 11d9 11d9 0049 7c38 8001 17c5 0000  .......I|8......
        0x0030:  0010 0001 0628 3633 3134 3737 3335 3539  .....(6314773559
        0x0040:  3031 3f34 3033 3230 3063 3161 3134 3930  01?403200c1a1490
        0x0050:  3931 3434 3530 3961 3462 6335 6464 6435  9144509a4bc5ddd5
        0x0060:  6261 6165 3561 3631 6333 64              baae5a61c3d
20:38:21.536154 IP 192.168.2.252.iax > 204.16.90.9.iax: UDP, length 81
        0x0000:  0014 f6e6 7c89 001d 72ac 2101 0800 45b8  ....|...r.!...E.
        0x0010:  006d 304a 0000 4011 5fc0 c0a8 02fc cc10  .m0J..@._.......
        0x0020:  5a09 11d9 11d9 0059 ea28 97c5 0000 0000  Z......Y.(......
        0x0030:  0038 0000 060d 060a 5363 6f74 745f 486f  .8......Scott_Ho
        0x0040:  6d65 1302 003c 3633 3134 3737 3335 3539  me...<6314773559
        0x0050:  3031 3f34 3033 3230 3063 3161 3134 3930  01?403200c1a1490
        0x0060:  3931 3434 3530 3961 3462 6335 6464 6435  9144509a4bc5ddd5
        0x0070:  6261 6165 3561 3631 6333 64              baae5a61c3d
20:38:21.576877 IP 204.16.90.9.iax > 192.168.2.252.iax: UDP, length 12
        0x0000:  001d 72ac 2101 0014 f6e6 7c89 0800 4500  ..r.!.....|...E.
        0x0010:  0028 99f3 0000 3211 0514 cc10 5a09 c0a8  .(....2.....Z...
        0x0020:  02fc 11d9 11d9 0014 339b a0b8 17c5 0000  ........3.......
        0x0030:  0038 0001 0604 0000 0000 0000            .8..........
20:38:21.577831 IP 204.16.90.9.iax > 192.168.2.252.iax: UDP, length 39
        0x0000:  001d 72ac 2101 0014 f6e6 7c89 0800 4500  ..r.!.....|...E.
        0x0010:  0043 99f4 0000 3211 04f8 cc10 5a09 c0a8  .C....2.....Z...
        0x0020:  02fc 11d9 11d9 002f 04a8 a0b8 17c5 0000  ......./........
        0x0030:  0011 0001 060e 0e02 0003 0f09 3132 3138  ............1218
        0x0040:  3737 3137 3106 0a53 636f 7474 5f48 6f6d  77171..Scott_Hom
        0x0050:  65                                       e
20:38:21.578004 IP 192.168.2.252.iax > 204.16.90.9.iax: UDP, length 64
        0x0000:  0014 f6e6 7c89 001d 72ac 2101 0800 45b8  ....|...r.!...E.
        0x0010:  005c 304b 0000 4011 5fd0 c0a8 02fc cc10  .\0K..@._.......
        0x0020:  5a09 11d9 11d9 0048 ea17 97c5 20b8 0000  Z......H........
        0x0030:  0061 0101 060d 060a 5363 6f74 745f 486f  .a......Scott_Ho
        0x0040:  6d65 1302 003c 1020 3064 6131 6431 3238  me...<..0da1d128
        0x0050:  3963 6238 3139 3832 6262 3935 3138 3066  9cb81982bb95180f
        0x0060:  6263 6539 6463 3332 3600                 bce9dc326.

Here is the protocol debug:

localhost*CLI> iax2 set debug on
IAX2 Debugging Enabled
Rx-Frame Retry[ No] -- OSeqno: 001 ISeqno: 002 Type: IAX     Subclass: REGACK
   Timestamp: 00057ms  SCall: 10251  DCall: 12086 [207.170.135.114:4569]
   USERNAME        : Scott_Home2
   DATE TIME       : 2016-10-24  20:40:52
   REFRESH         : 60
   APPARENT ADDRES : IPV4 ***********

Tx-Frame Retry[-01] -- OSeqno: 002 ISeqno: 002 Type: IAX     Subclass: ACK
   Timestamp: 00057ms  SCall: 12086  DCall: 10251 [207.170.135.114:4569]
Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX     Subclass: POKE
   Timestamp: 00007ms  SCall: 02337  DCall: 00000 [207.170.135.114:4569]

Rx-Frame Retry[Yes] -- OSeqno: 000 ISeqno: 001 Type: IAX     Subclass: PONG
   Timestamp: 00007ms  SCall: 00001  DCall: 02337 [207.170.135.114:4569]
Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 001 Type: IAX     Subclass: ACK
   Timestamp: 00007ms  SCall: 02337  DCall: 00001 [207.170.135.114:4569]
Rx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 000 Type: IAX     Subclass: POKE
   Timestamp: 00003ms  SCall: 04529  DCall: 00000 [207.170.135.114:4569]

Tx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 001 Type: IAX     Subclass: PONG
   Timestamp: 00003ms  SCall: 00001  DCall: 04529 [207.170.135.114:4569]
Rx-Frame Retry[ No] -- OSeqno: 001 ISeqno: 001 Type: IAX     Subclass: ACK
   Timestamp: 00003ms  SCall: 04529  DCall: 00001 [207.170.135.114:4569]
Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX     Subclass: POKE
   Timestamp: 00015ms  SCall: 10050  DCall: 00000 [207.58.213.177:4569]



[Russell Ault]

Returning to the OP's question (sorry about the hijack!), there are a couple of different ways to approach your goal (Palladium, two XM32 consoles, tablet control) which can be summarized as the "LAB" way, and the "Lounge" way:

The "LAB" way borrows heavily from another time-sensitive, UDP-based audio technology: Dante. Basically, if your network will happily pass Dante traffic, then a few OSC messages should be no problem. Audinate has networking how-to guides you can refer to, but the TL;DR version is that you should connect your Palladium machine and consoles to a good quality, managed, gigabit switch from a reputable manufacturer (the Cisco SG100 series is commonly suggested for Dante applications) and make sure to disable any energy-saving technology on it. I can't imagine a scenario where Palladium will generate enough packets to overwhelm a gigabit switch, so direct connections between the Palladium and the consoles shouldn't be necessary. For wireless control, attach a WAP to the switch (Ubiquiti Networks Bullets seem to be the flavour of the week). Assign static IP addresses to everything.

The "Lounge" way (also known as the "what I've been getting away with for years" way, or the "YMMV" way) acknowledges that any decent-quality SOHO "wireless router" product should have full-throughput switching (which isn't hard to achieve with only four or five ports) and acknowledges that Palladium's OSC data streams are, relatively, pretty small (a quick, back-of-the-napkin, calculation suggests that, even with two consoles and 24 controlled parameters per channel, which is about twice as many as I ever used, a full F8 Refresh would send only about 50 kilobytes of OSC data). All this is to say, get a decent SOHO "wireless router", plug everything into it, set your IP addresses so everything can talk to each other (bonus points with the SOHO router for having a DHCP server so you don't have to figure out how to set a static IP on your tablet) and give it a go. I mounted a (now discontinued) D-Link DIR-815 in the doghouse of my X32 not longer after I bought it and have never had any trouble getting OSC messages through it, from Palladium or otherwise, and it's only 10/100!

Of course, there's a lot of room between those two ends of the spectrum. My real advice can be summarized in three points:

1) Don't use Windows XP. Seriously, just don't. For anything. It's networking stack is laughable. Whatever problems you're trying to solve by using XP aren't as bad as the problems that XP itself will cause.

2) Don't overthink this. It's easy to get caught up in the "if a packet gets lost, it's gone forever" mindset and feel the need to do a lot of tweaking, but the reality is that modern computer networks (the wired ones, anyway) are astonishingly reliable, even the kinda cheap ones. Any half-decent gigabit switch (including the ones built into decent all-in-one "wireless router" units) is designed to pass several orders of magnitude more data than Palladium is going to be spitting out.

3) If you need to use LAB-level networking gear for whatever reason, great, but remember that everything fails eventually and nothing (not switches, not computers, not NICs, not cables) is perfect, and so the most important part of your network system design is a Plan B. 

(Incidentally, the most recent version of the OSC protocol does allow for the option of TCP communications, but to my knowledge MUSIC Group hasn't implemented this on any of their consoles. Perhaps it's time to submit a feature request...)

-Russ

[Dave Garoutte]

Returning to the OP's question (sorry about the hijack!), there are a couple of different ways to approach your goal (Palladium, two XM32 consoles, tablet control) which can be summarized as the "LAB" way, and the "Lounge" way:

The "LAB" way borrows heavily from another time-sensitive, UDP-based audio technology: Dante. Basically, if your network will happily pass Dante traffic, then a few OSC messages should be no problem. Audinate has networking how-to guides you can refer to, but the TL;DR version is that you should connect your Palladium machine and consoles to a good quality, managed, gigabit switch from a reputable manufacturer (the Cisco SG100 series is commonly suggested for Dante applications) and make sure to disable any energy-saving technology on it. I can't imagine a scenario where Palladium will generate enough packets to overwhelm a gigabit switch, so direct connections between the Palladium and the consoles shouldn't be necessary. For wireless control, attach a WAP to the switch (Ubiquiti Networks Bullets seem to be the flavour of the week). Assign static IP addresses to everything.

The "Lounge" way (also known as the "what I've been getting away with for years" way, or the "YMMV" way) acknowledges that any decent-quality SOHO "wireless router" product should have full-throughput switching (which isn't hard to achieve with only four or five ports) and acknowledges that Palladium's OSC data streams are, relatively, pretty small (a quick, back-of-the-napkin, calculation suggests that, even with two consoles and 24 controlled parameters per channel, which is about twice as many as I ever used, a full F8 Refresh would send only about 50 kilobytes of OSC data). All this is to say, get a decent SOHO "wireless router", plug everything into it, set your IP addresses so everything can talk to each other (bonus points with the SOHO router for having a DHCP server so you don't have to figure out how to set a static IP on your tablet) and give it a go. I mounted a (now discontinued) D-Link DIR-815 in the doghouse of my X32 not longer after I bought it and have never had any trouble getting OSC messages through it, from Palladium or otherwise, and it's only 10/100!

Of course, there's a lot of room between those two ends of the spectrum. My real advice can be summarized in three points:

1) Don't use Windows XP. Seriously, just don't. For anything. It's networking stack is laughable. Whatever problems you're trying to solve by using XP aren't as bad as the problems that XP itself will cause.

2) Don't overthink this. It's easy to get caught up in the "if a packet gets lost, it's gone forever" mindset and feel the need to do a lot of tweaking, but the reality is that modern computer networks (the wired ones, anyway) are astonishingly reliable, even the kinda cheap ones. Any half-decent gigabit switch (including the ones built into decent all-in-one "wireless router" units) is designed to pass several orders of magnitude more data than Palladium is going to be spitting out.

3) If you need to use LAB-level networking gear for whatever reason, great, but remember that everything fails eventually and nothing (not switches, not computers, not NICs, not cables) is perfect, and so the most important part of your network system design is a Plan B. 

(Incidentally, the most recent version of the OSC protocol does allow for the option of TCP communications, but to my knowledge MUSIC Group hasn't implemented this on any of their consoles. Perhaps it's time to submit a feature request...)

-Russ

I'm just lurking on this, but that was a great explanation.

[ProSoundWeb Community]