326. Part 2 Of “Anything & Everything” On AV Networking With Chris Lapp

In Episode 326, guest co-host Aram Piligian returns to join Andy for the second half of their conversation with Chris Lapp, developer of the new Open Fabric Studio AV network management software and senior specialist solutions engineer at Cisco and ask all about “anything and everything” AV networking. This episode is sponsored by Allen & Heath and RCF.

Chris Lapp leads the design and delivery of mission-critical media and data center infrastructure at the intersection of broadcast, IP networking, and AI. With a background that spans live production, large-scale data center architectures, and modern software-defined systems, he helps organizations build platforms that are performant, resilient, and ready for what’s next. Chris’s work focuses on translating complex technical requirements into practical, scalable solutions that support real-time media workflows and high-stakes operations.

In addition to his work with Cisco and developing Open Fabric Studio, Chris also serves as the vice president of Membership for the Society of Motion Picture and Television Engineers (SMPTE).

Episode Links:
STN Episode 325 (Chris Lapp Part 1)
Open Fabric Studio
jetfx (Personal Audio DSP + Guitar NAM)
More About Chris Lapp
Episode 326 Transcript

NOTE: Mike Green, the artist who performs “Break Free” that opens every episode, has released a new album — Hang The Moon: Part One — available on all streaming platforms as well as DSPs that support spatial audio. Mikegreenmusic.com will direct folks to the vinyl release or allow them to purchase digitally. And, Mike is hitting the road with Whitney Tai for “The Record Store Tour” starting May 23 in New Orleans. Find out more here.

Connect with the community on the Signal To Noise Facebook Group and Discord Server. Both are spaces for listeners to create to generate conversations around the people and topics covered in the podcast — we want your questions and comments!

Also please check out and support The Roadie Clinic, Their mission is simple. “We exist to empower & heal roadies and their families by providing resources & services tailored to the struggles of the touring lifestyle.”

The Signal To Noise Podcast on ProSoundWeb is co-hosted by pro audio veterans Andy Leviss and Sean Walker.

Want to be a part of the show? If you have a quick tip to share, or a question for the hosts, past or future guests, or listeners at home, we’d love to include it in a future episode. You can send it to us one of two ways:

1) If you want to send it in as text and have us read it, or record your own short audio file, send it to signal2noise@prosoundweb.com with the subject “Tips” or “Questions”

2) If you want a quick easy way to do a short (90s or less) audio recording, go to https://www.speakpipe.com/S2N and leave us a voicemail there.

Transcript

Episode 326 - Chris Lapp, Part 2

Note: This is an automatically generated transcript, so there might be mistakes--if you have any notes or feedback on it, please send them to us at signal2noise@prosoundweb.com so we can improve the transcripts for those who use them!

Voiceover: You’re listening to Signal to Noise, part of the ProSoundWeb podcast network, proudly brought to you this week by the following sponsors:

Allen & Heath, whose new dLive RackUltra FX upgrade levels up your console with 8 next-generation FX racks – putting powerful tools like vocal tuning, harmonizing, and amp simulation right at your fingertips. Learn more at allen-heath.com 

RCF and TT+ AUDIO.... Delivering premium audio solutions designed for tour sound and music professionals for over 75 years.  Visit RCF at RCF-USA.com for the latest news and product information.

Music: “Break Free” by Mike Green

[00:00:58] Andy Leviss: Hey everybody, welcome to another episode of Signal to Noise. I'm your host, Andy Leviss, and this week we're picking up where we left off last week in episode 325 with Chris Lapp and guest co-host Aram Piligian, talking about all things AV networking, Dante, AES67, I think we got a little ST2110 in there at one point, all the things, AVB. So if you haven't listened to episode 325 yet, definitely go back and listen to that first because we're going to hit the ground running literally exactly where we left off in that episode. If you have though, buckle up, enjoy, and here's the rest of that conversation on AV networking with Chris Lapp.

[[00:01:39] Chris Lapp: Yeah, I'll, the application will take care of all that for you. It will

not let you mix IgM P plus and IgM P, and it'll all be a standards based config not gonna lie to you. I'm not gonna do anything that's not standards based, but it'll be a standards based config. The IgM P stuff will match. The PTP stuff will match.

Everything, will check and balance to make sure that what you're trying to enable is actually possible on the hardware.

[00:02:00] Andy Leviss: That's really cool. That's, I'm, I'm excited to see where this goes and, and how it grew as and expands and, and since you're kind of teasing that there might be other applications within like the Open Fabric editor, I'm excited

[00:02:13] Chris Lapp: another one. There's another one already on its way.

[00:02:15] Andy Leviss: nice, I'm, I'm excited to see what that is. Um, let's see. I dunno.

Aram, do you have any questions about that specifically? Like, I know I certainly have like just some random networking and lightning round stuff I can throw out, but I don't wanna, I don't want to get us squirreling off in different directions too fast.

[00:02:33] Aram Piligian: No, I, I think that's fantastic. I think that's something that's, uh, very much needed, especially in, you know, an environment where, uh, everyone knows what an XLR is and what it does, and you do. You can pretty much plug an XLR cable from any console into any, or any microphone, into any console, into any speaker.

And the result fulfills an expectation. You, you kind of know what's gonna happen. And it sounds like you're on, on the path to achieving that with network switches, which is incredible, uh, because it's definitely been a journey. Uh, you know, uh, one of the things that I have. Absolutely experienced over the last, you know, 10 years of doing this is that not every, uh, not every

AV device is a great network device, kind of as you alluded to earlier.

And, and, uh, in all kinds of different ways, both from like raw performance and even just implementation and rules and IP addresses and subnets and, you know, what you're allowed to do and what you aren't allowed to do and how you get it all to work together. And, you know, the dr the dream that seems to allude me, uh, even after all these years to, is to be able to roll up to a system and only have to plug in one cable into one network on one vlan and be able to control all of the things that I want to control. And many vendors still, uh, you know, it, it's just not a thing, uh, which is. There's a lot of reasons for that, and that's okay. But I, I think move, you know, as we move towards solutions that enable people to get different vendors of gear to work together more and more like that is, you know, setting a standard within the industry.

So I, I'm really, really interested in seeing how this, uh, you know, is rolled out and as people start using it and sees the success with a tool like this to be like, yeah, I don't have to be locked into one vendor's thing anymore. I can now work across all of these things and get everything working together.

Nice. Uh, that's, that's the dream.

[00:04:55] Andy Leviss: I mean, I, I do tech support for a console manufacturer and a lot of cases we have on larger shows end up where they fall down. And where things get really weird is when there's like two vendors working together and two brands of switches and just something slightly different in how one's configured than the other.

And one, they combine them two networks that work perfectly fine on their own, suddenly just stuff goes off the rails. So yeah, having an easy way to like integrate, like multiple networks, multiple manufacturers and configurations is awesome.

[00:05:29] Aram Piligian: So if I'm, oh, go ahead.

[00:05:32] Chris Lapp: oh, so I was gonna say that one, one thing I think that the, the AV industry, or you know, just the device industry in general in our world could learn from the networking world is that, gosh darn, you should provide telemetry. Like there, there should be telemetry that I can get from your device. And I hate when people say, oh, just do SNMP. We work in a real-time environment. SNMP is not fast enough for pro av. It's not fast enough for broadcast, it's not fast enough for anything that you need to solve quickly. So if you want that, you should be implementing streaming telemetry with some kind of yang model for people to actually absorb that.

Like on change style telemetry, we do it in the networking world. When a port goes down, I can instantly send you a notification that that port went down. If a device is media port went down, I have to wait four and a half minutes for the next IgM or SNMP polling interval, blah, blah, blah, blah. Waste of time. Vendors need to start implementing telemetry and they need to standardize how they're gonna do it. On the device side, in the, in the 2110 World N Moss has kind of started that, but people aren't even doing it yet because they just don't wanna do the work. We need to do it. Us as the consumers of devices, and I'm gonna call myself a consumer because I still do shows. I mean, I'm not just a network guy. Um, we need to tell these vendors that make devices to implement these things because otherwise nobody's gonna do it.

[00:06:57] Aram Piligian: Yeah, cryptic error messages. Uh, don't help the end user.

Uh, No,

[00:07:04] Chris Lapp: absolutely not.

[00:07:05] Andy Leviss: That's, it's, it's, the tricky thing is, is somebody who's lived on both, like the support side, the development side, the end user side is like, you're always like, when you're writing code, you're writing manuals, you're writing error message. It's really easy to like forget that you know exactly what you mean when you're writing that and the end user has no idea what you.

And, you know, it's, it's, it's that looking at it and with the idea, like, no, that message makes perfect sense. And you have to look at it like somebody who's never touched it before and figure out like, okay, if I have no idea what you're talking about, am I gonna understand this or not? And like, I can't, like, I'm not even gonna point fingers in any one man.

Like, we all do it, like all manufacturers have these issues and it's, it's, these are things we can all improve, I think.

[00:07:51] Chris Lapp: And I mean, I'll point, I'll point the finger at myself for, for a bit, I mean not me as the developer, but at Cisco, right? Our sym 2110 routing solution, which we call IPFM, which is Nexus when, when a route failed, because there was no bandwidth. I had some string of 450 characters. That was some message id that meant that there was no bandwidth. Who the heck cares? So we went through this whole, whole process after we flagged it, being like, this is ridiculous. Like, why can't we just say route failed because no bandwidth. And so now in that system, when you go to the logs, it says route failed because no bandwidth. So we're fixing these problems on our site.

'cause you know. Users tell us these things and we fix them. Um, the point is that people need to tell people, and as long as we're listening, we can solve these problems.

[00:08:38] Andy Leviss: Dig it. Um, I have a bunch of like, like I said, like sort of lightning around things I wanna throw at you, but because you've mentioned 2110 a couple times, I actually did have a listener question that I will get yelled at if I don't. Asked this for somebody who, who has requested to go unnamed, but, um, just a, as from an audio person who's, who's more getting into like the broadcast side and dealing with things like 2110 more and more now was just trying to get a better understanding of like what, not necessarily what 2110 is, but like how does, like, how does it work in terms of like sync and clocking and stuff?

Like, is it similar to Dante? Is it very different? Does it not deal with that at all? Is there like a, I mean, obviously I know this is a subject that we could probably spend an hour in a into, but could you give like the quick crash course for audio folks who are finding themselves more and more in, in like a 2110 kinda world?

[00:09:28] Chris Lapp: So, uh, it it does work very, very similar to Dante. Um, I'm gonna say like Dante uses what we would call ate transport protocol or a TP. Um, so not exactly everything is the same, very, very, very close. Um, if we compare it to a S 67 instead, which uses RTP protocol, real time transport protocol, it's basically exactly the same. Um, everything is based off atomic time. So January 1st, midnight, 1970. That's the epic, the epoch. That's when time began. As long as you buy a clock that does that properly, um, I'm not gonna mention names, but there's a clock out there that uses a different epic as its default setting. Please change that.

'cause otherwise nothing works crazy. I know. Um, but exactly the same. So we have timestamps that are generated as we send out the media. That timestamp has to be the same as media's generated. At the same time, we use PTP to lock all these devices. And so when you reassemble the streams on the other side, they're locked together via PTP as well. Everything's exactly the same as 20 or as a s 67. 2110 video is actually easier than a S 67 other than the fact that it has a higher bandwidth. And the reason for that is the frame period of video is actually longer than the frame period of audio. So we have more time to do things properly in fixed kind of weird issues under the hood as we do an audio. I tell people all the time, audio is the hardest part of IP systems. It is the one that you should spend the absolute most time engineering video is just easy. I don't have that many video flows as compared to audio. I don't have to do things as fast. It's just, it just more bandwidth,

[00:11:06] Andy Leviss: Where, like what, 61 20 frames a second as opposed to 96 K is almost on the, is on the low side for a lot of things these days.

[00:11:15] Chris Lapp: Yeah. It's, I mean, I, I, I can't mention where it is, but I have a really big system out there that has, you know, roughly around 200,000 speakers in the building. Um, and, you know, sending flows to all those speakers simultaneously while keeping them all clocked. That's, that's a lot of hardware behind that.

[00:11:35] Andy Leviss: Okay. Um, so like in, in 2110, is it like, is there a similar concept of like leader clocks and that sort of thing? Or is

[00:11:41] Chris Lapp: it's the, the p the pt p is the exact same. Absolutely. 100% the exact same. And in fact. In any industry where we're using PTP, that concept still exists. There's the, the, you know, in the standard, I think we still technically call it the grand master in the standard, but you can call it grand leader. Um, I think we changed the standard to not say leader in it, but it says server and and follower

instead. But the same concept. Um, we're all still writing the standards to, you know, do all the politically correctness across like the 5,000 different versions of it. So everyone's kind of selling on a different thing. But net net you have somebody who's really in charge. Then you have people who are listening to the person in charge, and then they're distributing the orders to the people who are not in charge at all.

And then farther down, like, but that order of command stays the same across the whole thing. So there's always that very, very top one. And there might be some leaders in between. And followers. Followers. Followers. And that's financial. That's it. That's, uh, audio, video, that's, uh, power systems. We all operate PTP, like that.

[00:12:45] Andy Leviss: Copy. That makes sense. Um, so yeah, uh, a couple of kinda like a or B or, or, or like myth dispelling quasi lightning questions I wanna throw at you. Um. I guess the, this one is not entirely a lightning question, so I'll ease us into it, but like, I feel like when Dante first came around, everybody was like, oh, this is really easy.

Like, we're just gonna, we just throw unmanaged switches at it, you know, unless you're doing really crazy stuff, you don't need to worry about that. And that's definitely shifted over the, like 15 to 20 years into, we're almost always using managed switches. Um, obviously some of that is because unmanaged switches that play nice with Dante and don't have, you know, like energy efficient ethernet and all of that are just harder to come by.

But is that the, like, I guess at, at what point would you say that like an unmanaged switch is fine versus it's time to, you know, go, go to a managed switch or not assuming that EE and other things like that aren't a factor in the unmanaged switch.

[00:13:48] Chris Lapp: So a assuming that like eat trip, uh, excuse me, assuming that energy efficient ethernet doesn't matter and that it doesn't have it, like then, you know, a couple devices, no problem. Um, but my question to you would be, well, how much money is riding on this audio experience, right? Like, I always tell people like, if you're doing this for free, who cares if the audio goes out? If, if you're on the, the Super Bowl is an example, right? Like, you're not gonna use an unmanaged switch to handle your audio environment. So you kind of have to take that risk and like figure it out. Like, you know, where are you in that risk factor? Like if it's, if it's a high school musical, like I'm gonna use whatever I have in my basement.

Like, I mean, not everyone is like me and has $200,000 of switches in their basement. You know it, you just use what you have. But if you're doing a professional show and you're in charge of people's experience and they're paying money for that experience, you ought to be providing the hardware that delivers that experience.

Right? So that's kind of how I would draw it. It's, it's less about the capabilities, it's more about how much you can ensure that experience.

[00:14:50] Andy Leviss: If that's fair.

[00:14:51] Aram Piligian: So what are, for the people that are coming from the audio side and are trying to figure out, you know, trying to learn these things of like, what, when is this important? When is this relevant? How do I use this? Or what are the, are there any resources that you would recommend to audio humans that are moderately to, you know, decently experienced with, with networking and, you know, and not just Dante, but even beyond Dante and, and looking to kind of get a greater understanding of like, feeling confident in knowing what they're doing with this.

Like what, what are kind of the resources that they should be looking into?

[00:15:41] Chris Lapp: That's, that's a hard one. So, I mean, I do a, so if you're familiar with Cisco, we have this event called Cisco Live. And so I do a session on, uh, media and entertainment networking at Cisco Live every year. That's one resource you can have. I have a ton of white papers that I've posted. Um, I know that my peers at other companies have also posted very similar white papers, like the knowledge is out there. Um, but I'm gonna say this, and with love for everyone, the stupid questions are the ones that you do not ask. We are out there to help you, myself and all my peers at every other company that does these things. We are here to help you. And it, it's better that you ask us those questions before you just go do something and then it doesn't work. Um, I would rather spend 12 hours with you explaining how something is to be architected to work properly than having to come back and fix it later. Like it's such a painful process to do it that way. Um, I'm available on Discord. I'm available on LinkedIn. You know, like we're, we're everywhere. Like, I mean, just search for my name and you'll find that I chat on everything and you can always ask me questions. Um, and the same goes for most of us out there in the world that kind of bridge the gap between this entertainment world and the networking world. Um, there's even somebody like myself at Nvidia as an example, I'm not gonna give out his name 'cause I didn't, you know, get his permission. But there are guys who have worked in live entertainment who run. Things that Nvidia to make sure that Nvidia is doing things properly for this industry as well. So we're a force out there.

[00:17:14] Aram Piligian: No, thank you for that. That, because that's huge. 'cause I, I mean, you know, there's a big gap between, you know, hey, I got through Dante level three and. Hey, I have my, you know, Cisco switching and networking and routing certs. Like there, there's a big knowledge gap between those two things where a lot of this AV stuff falls where it's slightly more advanced or even more advanced than, you know, than what you would learn in some Dante classes.

But is kind of, you know, running the mill for someone who has a strict networking background. And I think kind of drilling the ho the point home that like there are humans behind all of this. There are humans that do what you do, who have had experience doing what you do and will listen to you, will engage with you and want to help you succeed. It's really important. 'cause I, you know, I, I just see so much of, you know, hey, I Googled or I chat GTD an answer to something that didn't get there because it's, it's working off of old, irrelevant, you know, information that's rotting somewhere on the internet. And there is a human whose entire job is to know this.

And if they can't, if they don't know it off the top of their head, their job is to find the answer for you. Uh, so engage with them. And this is to all of our audiences, like engage with the humans whose job it is to like, figure this stuff out for you because they want to, 'cause they love these kinds of puzzles.

[00:18:54] Andy Leviss: Yeah, there's, there's a handful of us nerds, again, to use the example of my job at Yamaha that like we are there all day long to solve problems and we love doing it. It's what we're there for and yeah. Will it take you slightly longer to get an answer from a human than chat GPT? Probably will that answer save you more time in the end because you know it'll be accurate also.

Yes.

[00:19:17] Chris Lapp: Yeah, I mean, and, and another thing is like, Andy, you know me like you can easily pull me a new conversation with a customer who's using Yamaha with Cisco, everyone at Ate knows my email address. So if you're working with Cisco and ate in the same network, I'm gonna get pulled in. I know people at Rele, I know people at Lavo, I know people at Everts.

I know people at Imagine Communications. I know people at Sys, they all, we all know each other.

And so hopefully. Before things reach, you know, the nuclear critical mass, the right people are pulled in, but the people who you know, you as the end users out there, tell them to pull us in. It's okay to say we need to get Chris from Cisco or Crico into this conversation,

[00:20:03] Andy Leviss: Yeah, like I've had piles of cases where like Brett at Auto, Nate will, you know, he'll start handling a case and I'll be like, oh, this is getting a Yao's domain. Let me go throw over to them. And like, you know, Jeremy or Jonathan or Andy will, will take care of you. Yeah. And, and yeah, with like, I've reached out to you a couple times for customers, like we've reached out to folks over at net year.

Like it's, yeah. It's what we're all here for. Um, let's see. Uh, okay. Other quick, I know we're like, we're already like over an hour, but like, I feel like this is one that people are gonna be super into. So, um, I, I do wanna throw a couple other quick of like, uh, this versus this or when to do something versus not questions at you if, if you're cool and if you're not rushing to get

[00:20:43] Chris Lapp: Yeah, I, I, my kids are asleep, man. I got lots of time.

[00:20:47] Andy Leviss: right. Um, so we, we talked a little bit about manage versus unmanaged. I feel like the other thing, like when we first learned about Dante, it was like, oh, it's got Qs, it's got all this stuff. We can just throw it on the network with whatever else is on there and not worry about it. And then we've kind of veered the exact opposite direction and we've all gotten really paranoid about like, Dante is only Dante.

We don't put any control on it. We don't put anything. Do you have a best practice for? Like where on that spectrum you would advise? Is it very much, is it an it depends kind of thing? Um, as far as like these different technologies being good neighbors or not when they should be isolated. At least if with VLANs, if not physical networks as opposed to when Yeah, no throat on the Dante network, it's, it's gonna be fine.

[00:21:28] Chris Lapp: So, so any two things that use PTP should be isolated from each other. 100%. They need to be on severed VLANs 'cause otherwise they crosstalk and things just don't work properly unless you're using boundary clock for everything. Like if you're using boundary clock again, that problem goes away. Um. QOS should be applied when you're not using boundary clock to PTP packets. But otherwise, if you know your audio's the only thing on the network or whatever, then it really isn't going to do anything to the actual payload packets as long as your switch is a good switch. But PTP should be prioritized when you are using something like boundary clock. It's automatically prioritized.

You don't even have to do anything. We, it just happens automatically in the back end of the switch. Um, you should never do a VLAN larger than a slash 24 for anything. Av please don't, don't do this to me. Um, I had a customer who, uh, I can't even remember the exact size of the site, or I think it was like a slash eight or something like that, which is like hundreds of thousands of devices. They were all just talking PTP, just in like regular multicast. And like, they're like, oh, well we turned the network on and with three devices it worked. And then we put like the 42,000 audio endpoints that we had on and it just didn't work. I'm like, yeah, well, it's never gonna work. I'm sorry. Like nothing I do will make this monstrosity

work.

So,

[00:22:50] Andy Leviss: hear Aaron's face right now.

[00:22:54] Chris Lapp: so it just like, don't do that. Automate somewhere in their documentation says that like, no more than 250 devices should ever be in the same vlan with Dante. It's in the documentation. And so like all the time I see customers putting like hundreds and thousands of, tens of thousands of devices and it's like, it, like it's not supported. And yeah, I'll, I'll try to help you. They'll try to help you, but at the end of the day, like hands are tied. Like we can't do what's not supported. And that brings me to my last point. Don't do what's not supported, especially if customers are paying money for the experience. Don't do what's not supported.

Check the supported guides. Like go onto, go onto my website and look at my switch. And we have verified scalability guides for how many multicast routes you can have. How many actual like Mac addresses you can have, how many of whatever thing you wanna do. I have a posted value of how many you can do of that thing. Don't go over that value. Check the scale.

[00:23:56] Andy Leviss: Just leaving some air for that to sink in for folks. Um, okay. Here, slightly, slightly easier question that although arguably gets into religion for some folks, uh, static versus DHCP versus, uh, link local a ppa. If we wanna, if we wanna be fancy about it,

[00:24:17] Chris Lapp: Um, yeah,

[00:24:19] Andy Leviss: doesn't.

[00:24:20] Chris Lapp: so I don't care if you do DHCP, I don't care if you do static, static reservations. I don't care if you actually do static, static addresses, but please, for the love of God, do not do link local. Like, do not do that unless like it's your basement network switch. Like that is okay and you know, but if people are paying money for it, don't do that.

Actually, this, this, don't do that quote is actually, um, Gerard Phillips, uh, my colleague that works at Arista, uh, kind of doing the same thing that I do. Me and him were teaching a sim bootcamp at NAB last week, and I told him that I was gonna quote him on that sentence for the rest of eternity. Don't do that. Like, just don't even try. It will work until it does not, and it's not our fault when it does not.

[00:25:07] Aram Piligian: So as there's sirens in the background, apparently. Uh, all right. That makes sense to me. You know, like, hey, the, it, it is more reliable to not be in a link local situation. However, I know of a lot of situations with various companies that I work with, you know, that where the pile of gear that you get on a show changes from show to show, to show, uh, like the, I don't have. I can, a company's not sending out reliably a package that, you know, the one switch to rule them all is always out with the package. Uh, the, there's various configurations of, uh, gear working with each other some days and not with each other, other days. And, you know, it could be a show with two switches.

It could be a show with 25 switches, and it's a different pile of gear every time. And the experience I have had is that the most reliable way to ensure that there is not, uh, conflicts between devices trying to hand out addresses, uh, is to just leave it all just vanilla Link local. I know that DHCP snooping exists, but it's not something that people always can figure on devices. From a standpoint of a vendor who needs to have a whole bunch of gear ready to go in all kinds of different configurations, is there any kind of best practice that does help mitigate the issues that you run into with Link glocal?

[00:26:59] Chris Lapp: And, and that is exactly why I created Open Fabric Studio. 'cause it will automatically configure DHCP snooping and it will let you configure A-D-H-C-P server and you can import and export show configs. So all that is in the application, but

without that, you're absolutely right. All those problems exist. Um, but like that, I mean, that's the nature of the beast, but yes, in in a tiny little show pack environment. Yeah. Like link local addresses are gonna work really good, but so would just a regular DHCP server and DHCP snooping and good old IT security best practices, blah, blah, blah, right? But link local addresses will fail you at the most critical time.

I can assure you of that at some point in your show career. And it's gonna be that one show when you really hoped it didn't

[00:27:48] Andy Leviss: It's gonna be that one time that somebody needs an iPad on the network really quick. Throws on a wifi router that has A-D-H-C-P server and suddenly half of your network is pulling DHCP addresses. Half is on link local and nothing can talk to anything else.

[00:28:00] Chris Lapp: Mm-hmm.

[00:28:00] Andy Leviss: Don't

[00:28:01] Chris Lapp: And

[00:28:01] Andy Leviss: I know.

[00:28:02] Chris Lapp: then you gotta figure out how to renew all those leases and

release all those addresses on the devices. And unless they're windows, I can assure you that's harder than you think.

[00:28:10] Aram Piligian: Oh, you mean reboot all the axion receivers? Yeah.

[00:28:13] Chris Lapp: Yeah. Yep.

[00:28:16] Andy Leviss: yeah, and I mean that's, I'll say like the one I, I feel like more networking support cases I see. And I, I didn't think to like pull any data to actually try and like back this up with numbers, but static, manually assigned addresses I find cause so, so many more problems for folks in our like chunk of the market because if we never have one person managing everything and tracking every device that's on it and that is a very, very quickly, you end up with duplicate ips and it's, you know, it is rarely idea goes by that I don't have like some problem with a, with a console or with wireless mics or, or something talking there that doesn't end up coming back to like, are you using static IP addresses and are you quadruple shore?

Every address is unique and.

[00:29:09] Chris Lapp: I mean, that's an interesting problem because a lot of people think like, oh, like it never experienced this problem where they have like 55,000 devices across a network and you know, they don't have, you know, IP addresses that overlap, but like we've solved that problem in it. We have things like IAM systems. More than one person can go. And, and for like build outs, like what I would equate to like a show build out, like there's amazing tooling out there, like NetBox, like multiple people can access a, like a configuration of a show. You can put it in this NetBox ecosystem and you can all just like add in your components and NetBox owns the con, NetBox owns the config of all those things. And then you don't have to worry about like Frank down the road accidentally, you know, configured this device as this, like, no, if NetBox owns it, then that's where, that's where it's in. So we solve these problems. It's just up to the industry to use those tools that are, again, open source and free out there in the internet to to make their lives easier instead of harder.

[00:30:06] Aram Piligian: And what it sounds like is honestly that it, you know, and. For a million different reasons. The AV industry is a little slow to getting to use and adopt the best practices that the IT industry has been using for years and years and years because of our specific circumstances. And, and, you know, it becomes this thing where it's like, Hey, I'm preparing for a show. One of the steps to prepare for a show is to prepare the network as if I'm installing a network on site somewhere. What are the steps that I need to, to accomplish this? And as from the background of like, Hey, if I throw this analog console and snake in a whole bunch of microphones and speakers in a truck, I can reassemble it on site without an issue. You know, there, there's some friction there. But this is becoming a vital step in the success of these shows that are so network dependent.

[00:31:05] Chris Lapp: Yeah, I mean like how, how many front of house engineers or monitor engineers, pre-PA, pre-plan their fader layout, pre, pre-plan, their, you know, input list, pre-plan, all this stuff, right? Like we, we've been doing that for a long time, but yeah, now you just kind of gotta. Pre-plan your network and pre-plan your IP address list and then just patch things around 'cause it's a lot easier. But we've been doing this for a long time. We just, for whatever reason, the AV and I mean even like the broadcast world, like they're just aren't doing it with the IT technologies. They just don't want to adopt it there. Um, and I guess it's not a, it's not a do not want, usually there's somebody or something blocking them from adopting it or it's a, you know, like a show pressure of not ever being able to get to that point where you can finally use the time to actually start that process. Um, but there are ways to do it. You just gotta not sleep for a night and just do it one night and you'll be fine for the rest of your life.

[00:32:02] Andy Leviss: I mean, why not sleep one last night?

[00:32:06] Aram Piligian: I mean, that makes me really excited for things like Open Fabric Studio and you know, the getting these kinds of management tools up and running quickly and being able to say like, Hey, cool, I'm on a show. I'm gonna deploy my network. The, you know, with the same ease that I sit there and deploy my wireless frequencies.

Like, I'm gonna make this work for me today, this week, this month. You know? And that's, that's where we're headed is just, uh, uh, and it's fantastic that, you know, we're starting to get some tools, thanks to you to get to that point.

[00:32:41] Chris Lapp: Yeah. And if there's any other tools or, you know, feature requests that people have for what that application should do, I mean, please let me know. I mean, post it in the GitHub. Um, and, you know, or email me or contact me on Discord or shoot me a text about dinner like Andy did today. Um, you know, whatever you need to do, get ahold of me.

Um, just let me know what you need and, you know, we'll find a way to make it happen, whether it's myself or whether it's 10 other people in the industry. We will make it happen one way or the other.

[00:33:10] Andy Leviss: Love that. Um, okay, two more, two more questions kind of dispelling some confusion I wanna do before we wrap up. Uh, one, can you give us the real quick boil down, uh, what is the difference between layer two versus layer three, and why would you choose one over the other?

[00:33:27] Chris Lapp: So layer two is when devices talk to each other over their MAC addresses or their physical addresses. Every single thing in the world has a Mac address. Hopefully it's unique. Uh, it should be unique, but not always. You know, we get clones out there. Um, as we discussed earlier, multicast shares, MAC addresses.

It's the only thing that is supposed to share Mac addresses. So whenever you talk over what we would call in the network world switching that is talking at layer two. As soon as you need to go beyond that, that's where we call it routing or layer three. So as you go from subnet to subnet, that is routing.

That's where we go layer three. So going from 1 9 2 1 6 8, 1 0.0 slash 24 to 1 9 2 1 6 8 2 0.0 slash 24. This is where we cross layer three bounds. And again, it comes down to scale or comes down to isolation, comes down to what we call in the network world, multi-tenancy as we need to go about those things, that's where we start to use layer three. In the media world, the end factor really is scale. Um, as you scale out these AV protocols, they tend to hate each other and tend to break each other as you try to shove them all together. So you must use layer three to go between different segments of those protocols.

So I guess net, net MAC address, IP address, layer two mac, address layer three, IP address.

[00:34:52] Andy Leviss: Got it. And I feel like, at least for me, like early on when I was trying to understand it, it felt counterintuitive me be to me because of that, that there's like more isolation between VLANs on layer two than layer three. Like once you wrap your head around it, it makes more sense. But like it definitely is, you know, you think like Mac address, well that's hardware.

So like, oh, they must all see each other and it's. it, it's in fact the opposite of that. Um, so I don't know, maybe I just told everybody that, like I used to be an idiot, but, uh, hopefully other folks are, uh, had, had, uh, similar either confusion or not understanding that. So I'm, you know, I'm happy to help clear that up.

Um, and then the last question I had, which is also, it's a, it's a big one to lobb you at the end is, uh, Dante versus a s 67 versus a VB versus moan, not, not, not saying which is better, even just like a little, I dunno. Can you use like the quick nickel tour of like, the differences in why you might choose one over the other, aside from just That's what the manufacturer I want to use as.

[00:35:53] Chris Lapp: All right. That, that's an easier question with the, you know, when to choose what one. So if I was setting up a stage and I needed to be fast, that's where I would use Dante, because Dante, in small environments is natively very plug and play. Um, if I was doing sound reinforcement, most of the time it's gonna be a VB out of like just the speakers that I pick, right?

Like, you know, Meyer d and b, all them, they're all generally speaking, um, a VB Milan. But if I need scale, and I'm talking like tens of thousands, 20,000, 30,000 streams, even, like even a thousand streams, like if I need scale with actual like resiliency, that's where I'm going with a 67 because it adopts all those good IT practices of being very scalable at layer two, but also very scalable at layer three, having a pluggable control, uh, mechanism, pluggable discovery mechanism, all those things are in a 67 where they're not in all the others.

[00:36:51] Andy Leviss: So in, in. At least the Dante implementation of ASS 67. It only supports a primary, whereas Dante supports secondary. Is that a limitation of ASS 67 or is that a limitation of how ATE has implemented it?

[00:37:05] Chris Lapp: That, that's the limitation of how ATE has implemented it. A 67 supports true like ST 2022 dash seven redundancy where it can do hitless merge across both interfaces. Um, ATE has that limitation because essentially they turn off their second transmitter on this other interface to now generate a Dante, Dante, and a is 67 stream on that primary interface.

So it's really just a hardware resources thing, um, from what I understand on the Dante side.

[00:37:31] Andy Leviss: Got it. So, so it's not, it's, they're basically taking wood would be the primary and secondary and making that a, a primary and an a s 67.

[00:37:41] Chris Lapp: Yep.

[00:37:43] Andy Leviss: Interesting. Um, and then I guess why is it something you can answer quickly to be like, why, like speaker manufacturers have tended towards like AV Beam Milan over a s 67 or Dante.

I know there's lots of, like, particularly with each of those manufacturers, like marketing speak about why, but I feel like being, coming from like the switch in network fabric side, you might be able to give a little more of, uh, a, a more nuanced, less, uh, less, we'll call it religious answer to that question.

[00:38:16] Chris Lapp: Yeah, so I, I, I guess I'll start by answering like, does it really matter today? Like, no, you can use whatever you want and like the latency of audio in our protocols today and running them in just generic CPU hardware is so good that we're not actually gonna detriment ourselves from using something like a 67 for, for speaker reinforcement.

And we do it in lots of places. Where Milan really has kind of like come from is like, before these other protocols existed, we needed a way to guarantee with absolution that audio was going to work. And I mean, think back to like the earlier days, like 10 gig links were even harder to come by back then.

Like one gig was primary, 10 gig was expensive, 25 gig was who knew, who knows? A 10 gig link is like cents now. 25 gig link is actually even cheaper than 10 gig. 400 gig is here and we're going 800 gig and 1.6 terabit now. So like those, let's let's call them guarantees of bandwidth resolution across interfaces.

Like we don't have to worry about that necessarily anymore. Um, but also like the, uh, Milan allows you to do the switch of audio within the frame period. So it's, you know, a kind of like a. A clean and quiet switch of audio is what I would describe it, um, as close to in the broadcast world. So it has those feature sets. Um, but those, those things could be easily achieved with a very small buffer on the device. And, you know, lossless and visual, I say visually, but audibly indistinguishable if you actually listened to audio coming outta a speaker. So when Milan started, all those things were 100% applicable. Like we couldn't do that with other protocols. Now we're kind of at the mercy of like, we could do it with all these protocols and at the end of the day, we need to interrupt all these protocols. Hopefully that answers it and doesn't make it more confusing. But, um, Milan had a lot of good things going forward in the early days. It still has a lot of great things going for it.

Like it is very interoperable between the devices to play, which is harder to do in like the other protocols that we have. But I don't think that the network level stuff that it, you know, promises is necessarily required anymore depending on the hardware that you're using.

[00:40:30] Andy Leviss: I think that answers it. Um, I mean, if, if folks don't, I'm sure I'll hear about it in, in a couple weeks. Um,

[00:40:37] Chris Lapp: yeah,

And the uh, the, the Milan guys are all, like, a lot of them are friends of mine too, and like, we can, we can argue about this all day, but the one thing that we do 100% agree upon is that we need to figure out a way for more network interoperability. So these protocols can all run together. Because if you can figure a network for Milan, holy cow, is it hard to get anything else to work on it? If you configure a network for Dante, it's hard to get anything else to work on. If you configure a network for a is 67, sometimes you're good, sometimes you're not. So how can we collapse all these protocols?

Like that's what we need to do next is the whole industry. How do we collapse all of these to say, I can deploy my network like this, and all of these things are going to work.

[00:41:18] Andy Leviss: yeah. If, if we answer that question, I will, I will be a happy, happy, uh, engineer with both my audio engineer and my tech support engineer. Hats on. Um,

[00:41:29] Aram Piligian: We, we've, uh, we've consolidated all the, all of these standards into one entirely new standard. And now we have one more standard.

[00:41:40] Andy Leviss: that's the great thing about

[00:41:41] Chris Lapp: I, I, I, I would argue that you have three less

[00:41:44] Aram Piligian: No, I, no, I, I'm, I'm joking, but no, that's a.

[00:41:47] Andy Leviss: Insert XKCD comic here.

[00:41:49] Aram Piligian: Yes. Thank you that that is, uh, exactly what I was thinking. No, it's, there's so much opportunity to be able to get the AV world, uh, to a point where it is as it commoditized as the rest of the IT world. Uh, you know, and, and I've said to people many times, it's like, other people have figured this out already.

This is, this is a solved problem. It's only, it, it only feels like a problem to us within AV because we're not there yet, but like all of the problems we are dealing with are solved problems. It's just a matter of adopting the techniques, tools, best practices that are needed to get there.

[00:42:38] Chris Lapp: Especially the tools, like don't be afraid to learn new tools. I, I'll tell you, when I first started my job out of college at the TV station. There was a manager there who told me that there would never be a time when broadcast was done in software. I mean, look where we are today.

Like every, everyone at

NAB is demonstrating software.

Like, it's like, you know, just don't be afraid. If you think that there's a problem, solve the problem. If you wanna solve the problem and you don't know how, come talk to me. Let's solve that problem together.

[00:43:14] Andy Leviss: I feel like that's the note we should wrap on unless, unless you've got anything else, Aram, that seems like a great way to tie it up.

[00:43:21] Aram Piligian: I mean, my, my only last thought was, you know, you, you mentioned way back at the beginning that you had, you know, a, a mentor for, from when you started doing like theater and, you know, and audio and what, uh, is there anything that really sticks with you from that experience that you've felt like you've carried with you, uh, throughout your journey?

[00:43:45] Chris Lapp: Yeah, so I, I always tell people that the best thing that you can do is mentor people. And, you know, your mentees don't have to be younger than you. They could be older than you. They could be somebody just looking for help. So I always try to pass knowledge on, I don't try and keep knowledge internalized.

I try and I'll literally talk about IGMP for a whole night at the bar if somebody wants to talk about it. I mean, it's a boring subject, but I will do it just because I love to talk about things.

[00:44:14] Andy Leviss: confirm both halves of that statement.

[00:44:17] Chris Lapp: so, you know, the, the thing that stuck with me is my mentors were never afraid to. Tell me when to be curious.

Tell me when, uh, that, you know, they weren't afraid to tell me when I was wrong either. Um, they weren't afraid to push me and, and make sure that I was doing things right, but the most important thing that you can always do is give recognition where it's deserved. And like I just made a post about this the other day, is that this industry as a whole has a big problem with recognition hoarding and and it is a curse and it is likely why this industry is still kind of stuck in this rut of not being as innovative as it could be. Yes, we're innovative, but we could be so much more. And as mentors and as people out in the industry, we really need to give credit where credit is due because it is super important that we empower the people who are gonna replace us to do the next thing.

[00:45:11] Aram Piligian: I love that. Agreed. Million percent.

[00:45:15] Andy Leviss: A hundred percent agree. Yep. Well, I think that's the note to wrap it up on then. So, uh, thanks Aram for tagging in and, uh, and, uh, taking Sean's, uh, spot for the, for the day while he was otherwise occupied. Thanks Chris, for finally, after a couple years or more of, uh, us trying to make this happen, coming on and hanging and we'll see if we get lots of more questions of stuff we didn't answer and if folks wanna, wanna have you come back on for more.

Um, thanks to Allen and Heath and RCF for sponsoring everything and letting us, uh, e Yammer on for the last hour and a half or so. And, uh, that's the pod y'all.

Music: “Break Free” by Mike Green