Forums › Forums › Qu Forums › Qu general discussions › 16 xlr to cat5e to dsnake or usb on QU16? for stage box.
- This topic has 33 replies, 8 voices, and was last updated 8 years, 6 months ago by Anonymous.
-
AuthorPosts
-
2016/05/11 at 7:12 am #55673dpdanParticipant
Eurekarem, sometimes, manufacturers design their equipment to use products that have already proven themselves as reliable, like CAT5/6 cable. Many times though, they come up with their own protocal to use on that CAT 5 cable that is NOT compatible with other companies like Yamaha, Soundcraft, Digico etc. It is common for guys like you and I to think that these companies do this so we have to buy “THEIR” accessories like stage boxes, power supplies etc. and we just feel trapped, or bullied as you put it into buying their stuff. Sometimes that is no doubt the case, Sony and Apple just to mention a few are notorious for that greed, but we still use their stuff because it just works….well most of the time ๐
The convenience of a digital stage box and a simple CAT5 cable sure beats the heck out of a 100 plus pound snake.
May I suggest that you purchase an AR2412 instead of an AB168,.. you may find it is not any more expensive, in fact maybe cheaper, and you get a lot more. With the AR2412 connected to your Qu16, you can now use the ST-1 and ST-2 as additional microphone inputs,… on the Qu16 that would give you a total of 20 mic inputs. To not waste mic inputs, it is ideal in most cases to use ST-1 and ST-2 for stereo sources like stereo overhead mics, or a stereo keyboard.
Just something to consider.
2016/05/11 at 9:59 am #55685MarkPAmanParticipantActually, ST-3 as well, so 22 mic inputs.
2016/05/11 at 11:18 am #55689eurekaremParticipantHmmm, good info guys,,, are the 22 inputs also available for inputs to DAW as well via USB?
Thanks.
2016/05/11 at 12:33 pm #55690LouParticipantYou haven’t been bullied; you chose the Qu system for good reasons. It is a system however, and if you want to build something to fit the protocol, go for it, but I’d rather be mixing music than designing a kluge ๐
Best,
<L>
2016/05/11 at 1:22 pm #55692MarkPAmanParticipant“are the 22 inputs also available for inputs to DAW as well via USB?”
Don’t have everything with me, so can’t test it, but it would but a strange one if they’re not.
2016/05/11 at 2:45 pm #55693eurekaremParticipantOk, thanks.
2016/05/11 at 4:30 pm #55695PeteParticipantHonestly, 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%.
2016/05/11 at 5:15 pm #55696AndreasModeratorJust 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.2016/05/11 at 7:09 pm #55699AndreasModeratorOk, 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).2016/05/11 at 8:00 pm #55700AnonymousInactiveShould be doable… You might need a hardware accelerated card though…
2016/05/11 at 10:41 pm #55702eurekaremParticipantHmm 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…
2016/05/11 at 11:01 pm #55703PeteParticipant@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.
2016/05/12 at 1:46 am #55704AndreasModeratorJust 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.2016/05/12 at 9:34 am #55708AnonymousInactiveThere 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.
2016/05/12 at 2:29 pm #55712PeteParticipantI 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.
-
AuthorPosts
- You must be logged in to reply to this topic.