Ok, thanks.
Honestly, you are going to have to buy an Allen & Heath product. I have a QU-24 and an AT2412. On stage, they are wonderful. Having spent a lot of my professional life in electronics, networking and computing, I looked hard at what A&H had done and decided that it was easier, cheaper and certainly better to buy rather than to build. The reason A&H use a proprietary protocol is that there does not seem to be an open source specification for digital snakes. Also running dSnakes through normal ethernet switches may very well work but I do not believe that dSnake is ethernet compatible. I can only believe that a collision on the LAN would result in an increased latency that might ultimately result in signal loss since I do not know how the dSnake protocol could make up for even a 0.1 second drop out given that there is a continuous and real-time signal stream going in both directions.
I was also very glad to ditch the huge and heavy copper snake.
One technical point that was not discussed is the usable distance you can send USB signals. This is 5 metres (16 feet 5 inches). Sure you can buy/build extenders but the AB168. AR2412 just works. 100%.
Just a technical sidenote regarding dSnake and Ethernet.
Of course the dSnake connection is 100% compatible to Layer 2 ethernet devices and works very well using switches and in particular VLANs (running other traffic along with dSnake through the same physical cable).
Using modern switches collissions may not occur at all due to store&forward mechanism and I really doubt the dSnake protocol implements any kind of packet loss detection and retransmission since it simply isn’t necessary.
I didn’t sniffed the dSnake protocol yet, but if each packet only holds a few samples, a single lost packet may probably simply be accepted without significant noise on the output system. Here we’re talking about fractions of a mSec not Second, btw.
Ok, for sake of curiosity I did a quick sniff and the “protocol” seems to be as simple as a protocol could be: It’s just a bunch of 24 Bit audio samples within a Layer2 frame (LLC) sent as broadcast packets.
The raw payload (about 217 Bytes) could hold up to 72 channels (we already have 40 monitoring channels from Qu to Stagebox along with the regular returns), so there simply is no room for a second sample but probably some additional protocol information (like box type, expander connected etc.).
Consequently frames are sent in about ~20µSec intervals, which nicely fit to our 48kHz samplingrate. Good luck in building something PC based to process that packet rate. 
If there is a packet loss, it would be a single sample only (on all channels, of course).
Should be doable… You might need a hardware accelerated card though…
Hmm this is getting interesting, thank you very much for the input guys, though some of the tech stuff is beyond my practical knowledge, I do understand it…
@andreas, Thanks for posting this. I was wondering what protocol, if any, was part of dSnake. LLC is a transport layer and as such has no flow control or even packet error management. There is nothing at all wrong with A&H doing that. Actually it’s a good thing because the idea is to get packets to an from the mixer and the stage box.
Obviously LLC can be routed via an ethernet switch and other hardware. The difficulty comes when there is a packet collision. Ethernet will buffer the packet whilst both ethernet adapters “time out for random period” and then resend. latency at that level on a LAN is acceptable. I wonder if the QU series has the ability to a). buffer and b). recover without increasing latency. I suspect that it can do neither. None of this is bad in a mixer.
To proves any of the above I would need a protocol analyser and try to remember from my early career days (it really was a long time ago when I was playing with this stuff).
My feeling is that the QU is best left connected directly to the stagebox (AR2414, AB168, etc.) via an unbroken cable that I think world be best if it were shielded. This last is just my engineering experience and opinion.
Really the opinion and advice of the design team would settle this but I doubt this will be forthcoming. Therefore follow the manufacturers advice would be my direction.
Just to repeat myself: Collisions on Ethernet were normal using plain old coax connections or using a Hub. Modern switches should support Store&Forward and transmitting packets only if the target port is idle. Since Twisted Pair connections provide separate lines for transmit and receive, collisions with the remote device technically can not happen at all.
In contrast: Running dSnake through a Hub does not work due to excessive collisions.
I’m using low-cost managed switches (TP-Link TL-SG105E) on both FOH and Stage with a GBit uplink, 100MBit on local VLAN ports and prioritized dSnake traffic. The uplink can only be loaded to max. 40% from the remaining four ports, no overflow could happen here. This setup provides WiFi accesspoints on stage and FOH for remote controlling the Qu from “everywhere”. Sorry to say, but this is proved to run rock solid.
Others are running dSnake through optical fiber to break the 100m/300ft limitation, works solid as well.
There is no packet collision in a modern ethernet network.
I’ve run 3 video streams (2 from Band to Stage, one from Stage to Band), and dSnake over a single fibre (so multiple physical media conversions) - we VLANned them apart, but they were all on one fibre. It was perfect.
There might have been an IP backstage comms link on the fibre as well, I’m not sure.
I agree with both of you that on a point to point network with only two nodes, collisions will not happen in this configuration. Collisions happen quite often on office and other facility LANs even with gigabit LANs if there are a lot of nodes and much traffic. I am sure that dSnake would not like sich collisions and may not know what to do about such resulting in lost data.
My point was not to suggest that collision would happen from stage to mixer as there is nothing to collide with. My point was more directed at the suggestion that dSnake could by put through an ethernet switch with the attendant risk of other (non dSnake) traffic being present. Thus the possibility of collisions.
Ethernet buffers its traffic just so that it can allow for traffic congestion where any node may have to wait for a clear path or a collision recovery. I cannot see how dSnake can effectively do this given the real time and low latency requirement of its design.
I also do not want to be involved in a bad thread discussion so now I’ll shut up about this.
Collisions don’t happen - networks are full duplex with store and forward, so there is only ever one packet going in each direction along a particular piece of cable.
Now a switch might have to hold a packet for a small fraction of a second, but that isn’t a collision.
For collisions you need either a non duplex system or a hub.
Both are now considered stone age.
Bob, Fibre or ethernet? Did you mistype or are you talking two different things?
Indeed, we’re running off topic, so I’ll also put a final note.
Using TP cables and switches there only are peer-to-peer connections with separated transmit and receive paths (full duplex connection). Technically there is no chance for collisions, even if plenty devices are concurrently connected to the same switch and sending data.
The switch exactly knows to which port he has to forward particular packets and keeps them inside internal send buffers until the target port is idle. There are also priority queues to decide which packet will be sent next and which may have to wait even longer.
The switch takes care of this, nothing the Qu or the stagebox has to bother with.
While there are no collisions, packet loss may still occur if the bandwith of the target port can’t handle the traffic in time and the switch runs out of packet buffers.
That’s why it is essential to prioritize dSnake traffic over anything else when building VLANs to ensure nothing gets lost there. Other communication like QuPad control are running via TCP which easily deals with lost (and even duplicated) packets.
@Lou
It doesn’t matter - collisions are a thing of the past.
You can still soak the bandwidth of a switch (the backplane is unlikely to be able to handle the full capacity of every port it has) causing packet loss.
One of the easy ways to do this is with a broadcast storm or, ironically, with Spanning Tree Protocol - which should stop broadcast storms in the first place…
Of course the real issue with the store and forward approach is jitter - you can’t be sure that the time between each packet is identical, especially if other packets are large. That requires careful network design/testing.