Anyone going to the SVSi training?
ericmedley
Posts: 4,177
I plan on it.
0
ericmedley
Posts: 4,177
Comments
Enjoy the BBQ!!!!!
AMX Managed Switches: I don't know really. I hope not. Selling our clients a rebranded box with a sticker over the old logo for 25% more than they can buy the exact same box of New Egg just doesn't fly as a business model IMHO... Commercial clients just aren't that dumb. Yes, We saw the SVSi product at Developers Conf this summer and it was obvious that the network had to be rock-solid. It, obviously, needs a well designed VLAN with (most importantly) the necessary trunk line bandwidth to traverse the network. I know a lot of the training has to do with this. I've designed some pretty heavy-lifting networks many times. So, hopefully, I won't have any issues dealing with this.
So far, it seems like a good solution and the video quality is hanging in there. I really want to get a couple boxes and play with it a bit. If it's a good solution I would love to start implementing it verses using the mega-switchers. The other issue that needs to be dealt with is audio distribution and how that gets broken out and what kind of latency/sync issues we'll need to handle.
JAP works by assigning each stream to it's own VLAN and then switching the VLAN assignment on the switch. SVSi uses IGMP to allow end point to subscribe and unsubscribe from streams.
My understanding is that this has already happened.
IGMP Snooping is one of those unfortunate terms that sounds much more ominous than it is. I find a lot of Network know-it-somes fear turning it on because it sounds bad or don't know what it does. There are ways to use it for a somewhat network hack if you are able to "walk" the SNMP tables. But all it really is is a nice way for the switch to make sure an endpoint member of the stream share is still there and manage the pipeline better. I will be curious to see how SVSi handles this.
I suppose it's a better term that "IGMP Flaming Stick In The Eye"
From here: http://svsiav.com/solutions/it-professional-qa/
So no, SVSi doesn't use VLANs for switching like JAP.
FYI, after much complaining Cisco corrected some of their DHCP issues on these switches where if you enter a mac in the static table but the client responded with a client id instead (usually 01 + mac) it wouldn't provide it an IP and if you assumed a 01 + MAC client ID and the client sent a MAC it wouldn't receive an IP. For over year if you wanted to setup static binds you would have to put all the devices on the network and 1st see how they responded before adding them to the static table, a real PITA especially if you had all the macs before hand. There were other issues but most of them have been corrected too.
Yea, you still need a layer three switch which is what you need for JAP, SVSi just does the streaming in a different (they claim better, but I've never seen a head to head comparison) way.
I'd love to go to the training to play and learn but I don't see an opportunity to use these in the foreseeable future.
My thinking is that I'd like to see this replace large frame video switching. i work in some situations where dealing with those big behemoths is costly and a pain. I'd like to see a solution that doesn't require a complete re-wire when the client wants to make a little change in the configuration or something that is more scaleable. I can put in a pretty beefy network for less than the cost of a big switcher system in many cases. If the quality and latency and reliability are up there, I'm pretty stoked about the possibilities.
With SVSi the video all lives on a single VLAN.
The way SVSi explained it to me, and it's possible I'm regurgitating this incorrectly, is that the JAP method relies on making changes to the network switch itself anytime you need to make a video switch. SVSi's method of doing it only requires that the end point request a different stream from the switch and nothing changes on the switch itself.
Again, I've never seen a head-to-head comparison with JAP (which I have also used), but I have used SVSi and it certainly works as advertised.
https://youtu.be/GGqcwdDW1a8
http://www.amx.com/products/categoryMinimalCompressionVideooverIP.asp
P.S. AVB changed it's name over to TSN (time-sensitive networking) to reflect the task groups shift in focus to general application of the tech.
FYI, the cisco SG300 or SG500 switches can be initially set to be layer 3 or 2. VLAN switching and igmp can be used in either layer but inter vlan routing (SVI, switch vlan interface) can only be done in layer 3 mode. There are other features that differ between the layer mode used too.
Some things...
The class had quite a few AMXers, mostly integrators and a few NASA engineers. (And yes - they were indeed wearing pocket protection - i s@%*t you not..)
The technology seems pretty solid and well-thought-through. Most who were already using it said there were only one or two 'gotchas' that were specific with the SVSi side. (Basically a couple settings that one can often forget to click over after setup that trip you up) If there were any common trouble spots to implement it had to do with the IP Network infrastructure. They did provide pretty full service network config if you buy the hardware from them. It comes fully configed and ready to go. Didn't get any prices for it but by all counts there seemed to be some push-back from clients who can buy the same gear for less. But they then spend more time/resources getting it configured correctly - thus making the initial cost not seem so bad after all.
SVSi has its own control interface via either a in-wall keypad/touchpanel that is fairly programmable via Java Script. It's one of those things that for basic control it was fine, but for more complex integration it got weird fast. But, for the most part - basic control can be done without a control system. The matrixing is very simple and completely grainular. just grab what sources and endpoints you need, throw them on the network and start matrixing. It expands and contracts with no effort other than adding another box.
The video quality is good with little artifacting. Home Theater quality??? Not really. but, I'd install it as a distributed video solution with no shame at all.
On the AMX/SVSi/Harmon angle - You can tell they are getting used to the idea that they are now part of Harman and that AMX is going to have a big say in what they look like in the future. They don't seem to mind it much and look forward to it. But, there are those pregnant pauses in conversations as you can tell they're thinking hard on their feet just how to phrase things.
My takeaway is the system is really good and I can see abandoning the large frame switches for commercial video distribution. It's just much more simple to manage and much less hardware dependent. Plus, IT people seem to get it better. My big worry was audio-only issues, and they had a box for that. In fact, the streams can be fed directly into the QSC Audio DSP with no box needed inbetween.
While the control interface/API is not difficult, I do really hope they make the whole mess Netlinx Native. If not, I'll just write a module and call it good. One thing to pass on that we programmers should keep in mind: Yes-you can control the individual Encoders/Decoders from AMX. Each box does come with a serial and IR port to control whatever it is they are connected to. They also have a IP Passthrough as well. BUT - it is very much advised that you include their server box that acts as a gateway for control. To mainting a large number of IP ports on the AMX side can be a bit much. It's much easier to just talk to one box and let it act as the operator to get the message to the right box. Plus feedback is much more streamlined. There are two flavors of server (I think the model numbers were 8001 and 8002) The smaller only allows for 50 devices and 5 butts in the seat. The latter is unlimited/unlimeted.
In both cases neither box added that much to the overall bid. If you're doing over 50 sources/endpoints another box is not going to make a blip on the radar.
So, my overall reaction is very positive. I all works as promised and I cannot see any fatal gotchas lurking in the wings. They've deployed some enormous systems (well over 5000 sources/endpoints) and I've checked with the clients and they are all smiles. The staff are all young and hungry and positive.
I had someone from SVSi tell me a few weeks back that they had already made their stuff Netlinx Native. Is that not the case?
Well, the answer is no. but, perhaps I better define my terms. By Netlinx native I mean that when you plug in an SVSi box (encoder, decoder, etc...) it connects to an AMX master and shows up as a netlinx device.
So, having set this table, If that is what we are talking about, we were not shown any such thing. Here again, what was there was quite useable and nothing problematic. I hope what you say is true as I tend to like to feel like AMX does a pretty good job of managing the connection of stuff and the less I have to manage the comms in code, the better my day seems to go.
It's possible that the SVSi person I talked to had a different understanding of Netlinx native than you and I do.
I've used SVSi with AMX in the past and never had any issues controlling it. Trying to use the SVSi internal panel building application though, let's say I'll be happy to never do that again.