267. Frank Padikkala Of Audinate Talks Dante

Frank Padikkala of Audinate joins the show in Episode 267 and talks with Sean and Andy to talk about all things Dante. Frank is a senior technical sales engineer for Audinate, and brings his years of experience in IT/cybersecurity as well as AV integrations together to help clear up a bunch of common misunderstandings about Dante and AV networking in general. From IP addresses to managed versus unmanaged switches to VLANs and more, get ready to peel back the layers and learn how to make your audio networking life much easier and more reliable. This episode is sponsored by Allen & Heath and RCF.

Episode Links:
Dante Training and Certification Resources
Best Practices for Managing Dante Devices
Dante Whitepaper Library
Episode 267 Transcript

Be sure to check out 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

Signal To Noise, Episode 267 Frank Padikkala Of Audinate Talks Dante

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, introducing their new CQ series, a trio of compact digital mixers for musicians, bands, audio engineers, home producers, small venues, and installers that puts ease of use and speed of setup at the heart of the user experience.

RCF, who has just unveiled their new TT+ Audio brand, including the high performance GTX series line arrays and the GTS29 subwoofer. Be sure to check it out at rcf-usa.com. That's rcf-usa.com.

Music: “Break Free” by Mike Green


Andy Leviss: Hey, welcome to another episode of Signal to Noise. I'm your host, Andy Leviss, and with me, the Linkwitz to my Riley, Mr. Sean Walker. What's up, 

Sean Walker: ha ha ha ha! Every time. You get me every time with those. That's freaking funny. Ha ha 

Andy Leviss: gotta keep it thematic for the last couple episodes. We were talking about crossovers a little bit, so 

Sean Walker: Man, I'm awesome. I could not possibly complain. Every, every problem I got is a first world problem and nobody wants to hear it, you know what I mean? 

Andy Leviss: yeah. I said you still sound a little under the weather, but you're smiling, so we'll take it. 

Sean Walker: Yeah, yeah, I'm still a little stuffy but I'm, I'm getting better. You know, every day better than the last, which is good. So and it's just a, you know, it's a little, little sniffle. It's a little man cold, as it were, as my wife would say. you Turns every, uh, every big tough bearded dude into a little whiny baby in two seconds flat and just spend days going, I went my momma, wean, wean, wean, she's like, you, where'd my big tough guy go you whiny little baby pants? 

Andy Leviss: I mean, I don't want, I don't want to talk about whiny babies because I got like, we're rockin real close to mine could be here any day, any week now, so. That's, in fact, the second we get done on this recording, I'm zipping up a suitcase and going on our last little kind of mini babymoon. 

Sean Walker: Yeah dude, that's gonna be sweet. You're gonna be a good dad dude, just make me fun. 

Andy Leviss: I got the jokes already, so. 

Sean Walker: yeah, well I mean that's all there is to it really, just, that's it, bad dad jokes. And you get it nailed. 

Andy Leviss: Right? Uh, cool. Well, why don't we, let's, let's, let's hit it hot and heavy now. We should introduce our guest, and 

Sean Walker: Ooh, ooh, ooh, that's how you get the first kid in the first place bro, easy killer. 

Andy Leviss: Hey now. Um, you know, Frank, I realized the one thing I should have asked before the podcast was to have you say your last name so I don't mispronounce it. So why don't you introduce yourself? 

Tell us a little about you. 

Frank Padikkala: Hello, hello, this is Frank Patekala, uh, happy to be here, this is awesome. I have listened to several of your podcast episodes, uh, so I kind of feel like a celebrity today. This is, 

Sean Walker: You are. 

Frank Padikkala: Thank you. This is pretty awesome. Uh, so I work for a company called Audinate. Uh, and it's funny, sometimes when I say the name of the company, it doesn't ring a bell, but when I say Dante, ding! 

You know, it, it triggers like, oh, I know Dante. So, I'm a Senior Technical Sales Engineer. Uh, I work for Audinate. I've been with them for close to three years now. Uh, Interestingly enough, uh, my background is in IT, networking, and cyber security, so I don't come from a traditional audio or video pathway, uh, but I've worked the better part of my career in AV, uh, did a lot of commercial design, uh, was a design engineer with an integrator, and then Flipped over to the manufacturer side, uh, worked a lot on, uh, uh, a video solution, a video mixing, IP based video mixing platform, um, and, uh, then have been at Audinate. 

So that's, uh, that's a quick look at what my career over the last few years has been looking like. 

Andy Leviss: Right on. Well, and, and we've been trying to get you on the show for a while 

Frank Padikkala: Yes, I know this is like the worst case of TAG that we've ever played. I think this has been going for six months to be honest. We've been 

Andy Leviss: I was going to say, I'm trying, I'm trying to remember if we were actually like expecting the baby one because you and I were talking and 

Frank Padikkala: So I didn't know about the baby So that's how long that we've been trying to do 

Andy Leviss: Yeah. Cause, uh, 

Sean Walker: and, Frank and Merlin it's been 

Andy Leviss: Yeah, yeah, it's this is our month of like finally catching up with stuff we've been juggling schedules on for a while. 

But uh, yeah, so Frank actually got to meet Kate at an Infocom, which I couldn't join it. So they were all trash talking about me while I was stuck here in New York working. 

Sean Walker: Well at least you got to beat the better half, I mean, you know. Yep. Yep. 

Andy Leviss: absolutely. Absolutely. I 

Frank Padikkala: that's what I loved about the first email It's like I'm not the best audio engineer in my own household. You sold me with that. You know, it's a good number two Love that. I love 

Sean Walker: totally. 

Andy Leviss: Yep. 

Sean Walker: it keeps you out of the doghouse, bro. Totally, 

Andy Leviss: I mean, I've seen her make shows. I've seen me make shows. It's just fact. 

Sean Walker: There you go. I'm gonna start calling her for shows then. 

Andy Leviss: yeah, go for it. Um, anyway, so yeah, we wanted to get you on like I, because I reached out to a couple of folks at Audinate that I was talking to about different things. I was like, you know, we should get one of y'all on to talk and kind of talk about like common myths, misconceptions, myth conceptions, if you will. 

And, uh, because I, I mean, I guess we should zoom out real quick and just On the rare chance of the few folks listening who might not be familiar with Dante, because I know like I, I used to work for an integrator as well. And I remember going to do a training a couple years ago where the the two, you know, guys that hired temporarily as the house sound engineers were there and my boss and I thought it was going to be a nice short hour long training. 

And we're getting ready to patch on the console. We're like, Hey, help out like, you know, how familiar are you with Dante? And they looked us deadass in the face and said, who's he is he from around here? 

Sean Walker: Oh no. 

Andy Leviss: And we cleared out our afternoon service call. But on the, on the off chance there, there's to, to be fair, there's nothing wrong with not knowing what it is. It was just not what we expected in that situation. But since we may have some listeners who, who maybe don't know what Dante is, why don't you give us the quick, the quick and dirty overview for those folks. 

Frank Padikkala: absolutely. So, um, it all started with a great company called Audinate that's based out of Australia. A couple of really smart people came together and they were trying to solve a problem. And oddly enough, it's the live events, the music side that kind of drove the initial development behind Dante. 

Uh, uh, one of our co founders and CEO, uh, he loves his music, uh, and he looked at that huge bunch of cables every day, uh, as he was trying to do something and he thought, Surely there's a better way to do this. Uh, and that is kind of how they began research into how you can optimize and put audio on the network. 

Uh, and they developed Dante as a technology. Uh, so the, the foundational, the initial foray of Dante into the world of audio was as a solution that enabled manufacturers and solution builders to create, uh, uh, Their audio platforms stick to their core strengths and rely on Dante as its mode of transporting the audio over a network. 

Uh, so essentially, you have these hundreds and hundreds of channels of audio that can go over a single Ethernet cable, uh, regular switch that you can find, you know, and I think one of the initial, uh, marketing, you know, messaging that we tried to put forward was that it just works. And that's pretty much true. 

You take a couple of devices that are Dante enabled, you plug them together, open up Dante controller, which I think is one of the most popular softwares, uh, worldwide. I don't know how many hundreds of thousands of millions of downloads that software has, just download it. You can see all your Dante devices and poof, do your routing. 

So it's simple as that. It's a, it started off as an audio over IP platform, but like with every technology, the evolution has. Kind of led us into video and cloud based stuff, so it's, it's grown a lot. The company has its, uh, it does a lot of different things, but at its core, our biggest strength has been audio. 

Uh, that's where we started off, uh, just to throw in some fun stats there. Uh, of all the, uh, audio over IP products that come out every year, We own about 90 percent of the market share, so every year there's new solutions coming out. Uh, the easy part of it is that because we build the interop into the functionality of these solutions, nobody has to worry about a Dante device not working with another Dante device. 

As long as it's Dante enabled, It will work together. So that guaranteed interop has strengthened everyone in the food chain, whether you're a microphone builder or a speaker manufacturer, or you make mixers or mixing consoles, as long as it's Dante, it just, it just works. Uh, That's kind of like the foundational piece of it. 

The same principles apply now, even if we go into video or cloud based Dante. Same principles. We want to make sure that the user experience is simple, where you can just essentially make it work. But, here's the complexity of it, and that's probably what you dealt with on your first thing. There is a network involved, right? 

The challenge with networking in media, in audio or video for that matter, is that the general perception of a traditional Media professional is to look at it as a cable replacement. They look at it. Oh, I mean, I'm taking my XLR connectors. I don't not do that anymore. I can use, uh, my, my, uh, my RJ 45s category cables, replace microphone cables and speaker cables. 

Great. It's a cable replacement. That's not entirely true. A network is actually a living, breathing ecosystem within itself. And having some understanding of the network will help you, you know, avoid the most famous Words of every audio tech out there. It's not me. It's the network. You know, it's like that's how you, you know, knowing some of that will help you not say that. 

So, uh, that's kind of like a quick look at what Dante is and, uh, where it falls in that, you know, this very busy world of audio and video and networking and all that stuff. 

Andy Leviss: Yeah, and I mean, I will, I will date myself a little bit here and say like, the, the, it just works ness of it from somebody who like first grew up with like RockNet and and Co Burnett is like, you know, as, as much as like when you get to a complicated system, you can have some quirks that are, I think usually more on the network side. 

And maybe we'll get into that a little bit. It's, it was, it was a night and day, like simplification of stuff when Dante first like popped on the scene. 

Frank Padikkala: Absolutely. Absolutely. And it's, it's, it's interesting how it's evolved. to essentially becoming a basic foundational skill for a professional on the audio side today. Uh, it, it'd be hard pressed to find somebody who hasn't used or, with Dante at, at some level. And I think over the years with all the different products that have come out, we have lowered the barrier to entry. 

I mean, our AVO adapters, which are like, you know, the, so, uh, FYI for the listeners of this, Wonderful show. Audinate doesn't actually make any end user facing products. We have a very few of them. There's our software solutions, so your DVS, Dante Virtual Sound Card, if you use that. There's our Dante Via, uh, on the audio side, which is essentially like a, it's like a hybrid kind of software based platform that does Dante transport. 

Uh, and we have avios, which is our, uh, Those little dongles, adapters that you see flying around, essentially network cable on one end and, you know, uh, uh, XLRs on the other end or USB or Bluetooth and essentially takes audio and converts it into it. Those are like, those retail, you know, somewhere, A hundred ish bucks on, you know, your retailer of choice, uh, easily available. 

So you can essentially build out a very simple Dante's network with very low inve investment. And then the good thing about it is that as you build your platform and add more devices, you're not replacing any of these devices. You don't need to add channel count to any of them. You just add a network switch. 

It just needs network port. So it's like, it's a different concept from a design perspective, but functionally. It is still the same, you know, ultra low latency, uncompressed, high quality audio. Uh, and that's uh, that's how it's grown. So it's, it's interesting to say, see where Dante is today compared to when it started off. 

That's uh, that's yeah, 

Andy Leviss: Yeah, I mean, I remember being in the early days, like I had, there's a Broadway sound designer who he would always on a show, like put one new piece of technology on every show, you know, in a place he knew is safe. And he had a show that he had done. over like ADAT connections from like RME, you know, audio interfaces at its original production, and it made a commercial transfer. 

And he was like, that's the perfect opportunity. Like, I've been hearing about this Dante virtual sound card thing. I'm going to try that into like a DM 2000, like Yamaha console with the Dante card, and we're going to give it a try. And I built the rig for him. And like, after the second day of rehearsals, he just texts me on the, you know, emails me and is like, Andy. 

It's like mainlining QLab. It's like, it's like I just put an IV of QLab right on my arm and it's there. It's like, it's, and that was, that was the very first, uh, virtual sound cut on Broadway as far as I'm aware. 

Frank Padikkala: Wow. I mean, I need to take this back to our folks. This is great information. I love this. 

Andy Leviss: yeah, I thought it was, 

Frank Padikkala: love a good history lesson? This is fantastic. 

Andy Leviss: it was, it was the, the commercial transfer of Venus and Fur, uh, with Nina Arianda and Hugh Dancy, uh, back in longer ago than I care to admit. Wow. This is the day between that and the baby talk. This is the day for making me feel old. 

Sean Walker: Oh man, don't worry, it's just the gray hair in your beard that makes you feel old. 

Andy Leviss: Ah, 

Sean Walker: Welcome to the club, bud. 

Andy Leviss: right. Um, yeah, I mean, I guess, like, maybe we should start with the basics. Like, you know, the, one of the questions that always comes up when Dante comes up and that seems to become like a religious war almost, link local versus DHCP versus manual IPs, obviously it'll work with any of them. And I feel like at a certain point it became like the common wisdom to like, always set manual addresses so you know what's what. 

And I know the guidance from y'all, unless it's changed, has generally been like, Yeah, unless you need to, just let it link local and let it do its thing. And I know that's when we reach out for questions a while back from folks, that was one of the questions lots of folks had, is the why or why nots of 

Frank Padikkala: Yeah. Yeah. That's a, that's an excellent question. Uh, so, uh, yeah. Like you said, it works on all three. I mean, it could be link local, manually set static IPs, or DHCP based. But I think the, we need to take the question back to probably the size of your Dante network and what exactly you're trying to accomplish. 

What are some of the requirements? How big of a network it is? So, um, an interesting way to look at this and, you know, that's kind of how we've structured our training. So You know, if anyone's not done the trainings before, check out our website. We have our Dante level 1, 2, and 3 certifications essentially giving you like a pathway into understanding Dante both from the component audio functionality, media functionality side, and also going back to the network and how that's, how that's being set up. 

Uh, level one essentially deals with a single switch. I think of it as like a single switch environment where there's, you know, one switch. Plug them in, and that's it. If you're looking at it from the perspective of it's a switch that's dedicated to this purpose and you don't anticipate any other network traffic on there, it's, it's just Dante, nothing else, then it's perfectly fine to do LinkLocal. 

Uh, and it just works. Again, uh, that's kind of how it works within that single subnet environment. It's, there's a lot of traffic that goes behind the scenes to make sure this is enabled. Uh, there's, uh, essentially like a process by which this is done. Devices are discovered, uh, and essentially a lot of devices talking to each other and saying, Hey, I'm a Dante device. 

I'm a Dante device. Can you see me? Can you see me? And then what happens is it all populates into Dante Controller and then you do it. So link local is perfectly fine there. When you get into a multi switch environment, Uh, that's when things get a little bit more dicier, and this has nothing to do with Dante in itself, it's just the way how networks are architected, because when you look at traffic from a switch to another switch, uh, you're actually sending multicast over some form of a, a pipe that you've established between the switches, depending on the switch manufacturer, there could be a 10 gig uplink, doesn't, we don't know what that is, but, uh, In a multi switch environment, multicast is actually one of the pain points, and unfortunately, here's where I think we're at. 

Everybody has a little bit of a problem understanding, you know, multicast in general, because even a network engineer who's really good at building switches and setting, building out network processes, and is a network engineering whiz, the problem is a lot of times the knowledge level for managing multicast comes at a much higher level. 

Cause Typical traffic in the non media environment, even though there is multicast, is so low bandwidth that it's not too much of a concern if something were to, say, go wrong. There's very little multicast, but even whatever multicast there is, Not that much of a concern because you're looking at emails and you're looking at, you know, VoIP calls, which are kilobits, right? 

Now, audio steps that up a little bit. Quick trivia, uh, does anyone know how much, uh, audio, uh, how many, uh, like what's the bandwidth requirement for Dante? Anyone? 

Andy Leviss: I should know this, because I've passed all three levels, but it's too early in the morning and my brain isn't 

Frank Padikkala: That's not a problem, that's why I'm here. Uh, so essentially we have what is called a Dante flow. A Dante flow is kind of how we kind of package our audio channels. A flow has four channels of audio, and four channels of audio takes six megabits per second. So it's six Mbps for every four channels of audio. 

So if you're looking at 40 channels, It's only 60 megabits. If you're looking at 400, it's still 600. So it's not like you're saturating a one gig link, even if you have hundreds and hundreds of hundreds of channels, right? Multicast can quickly, you know, make the effects much worse than it is if it's not properly managed. 

Now, as a, uh, as a quick, uh, note that I, I like to do this in all my teaching sessions, unmanaged multicast is broadcast. And nobody wants broadcast, right? So that's when you have a multi switch environment. You need to manage things a little bit more and in those kind of situations, having a network plan usually entails also key, uh, Creating an IP address scheme, right? 

So it's easier for people to manage a list of IP addresses when it's a larger network and say, all right, this Yamaha mixer is always going to be 192. 168. Uh, 1. 250 or whatever, you know, and you can assign, uh, IP addressings, a manual becomes fine. Now, when you're dealing with larger corporate environments or multi switch stacks, data center type models, where there's hundreds and hundreds of devices, just creating an Excel sheet with like a 200 or 300 of different devices and their MAC address and their IP address, that is a pain point that you don't necessarily need to do. 

You can perfectly rely on DHCP to, uh, provide the IP addressing and just set the, you can set the reservations, you can set the address schema and have it efficiently rolled out. So, the question about IP addressing depends a lot on the size and the needs of your deployment, uh, and that's kind of how we've structured our training too. 

So, level one, single switch, level two. Multiswitch, Level 3, larger corporate, you know, enterprise level network. So that's your rule of thumb when you're trying to build out a Dante network. 

Andy Leviss: got it. So, so like the, the guidance that people say, and it's kind of maybe blindly repeated a point to like, no, no, automate says, just, just use link local. That's basically the, with the asterisk of if you're on a simple, straightforward system with like a single switch, maybe two switches, it's, so it's, it's not the, it's not the link local is better in that situation. 

It's that it's just, it's just. Easier to set 

Frank Padikkala: It's easier to set up, you know, and because that's the comfort level a lot of people have. They still want to be able to plug in a device and it just shows up on their network. The problem then is like when you have 50 devices or, you know, 60 devices, you have a lot of devices to plug in and then you're plugging them in and then things don't work. 

And then you're like, Oh, you know, what am I supposed to do here? Uh, the network needs to be planned. I think that's the lesson I'm trying to impart here. It's like, it's important that we. Put a little bit of thought into what's going on in your network, just like we would with our audio channels, the principles of design in engineering always overlap, you know, I hate to say it, maybe the skills of building a network, yeah sure, an audio engineer doesn't necessarily need to know how to configure a switch, but They are the expert in terms of what audio is being utilized in a particular activity. 

Uh, the thinking about what goes on the network is just a little, a small extension from that. Right? And that's where I think we need to meet with the folks who design your networks, right? And that's where we don't meet. Like we kind of like say, I don't care about your network, this is what I need on my audio. 

That doesn't work because the network people don't know what audio you're putting on their network either. So it's like, you know, we need to meet closer for these, you know, uh, unfortunate incidents to not happen, you know. And, and a lot of times it's communication, uh, that can solve these things and communi lack of communication that prevents proper deployments. 

But yeah, it's, uh, I'm sure everybody has their own support experiences here that they don't want to talk 

Andy Leviss: it. Lack of communication preventing proper deployments is, uh, is Sean and I's life half the time. 

Frank Padikkala: You go. 

Andy Leviss: As I wake him up at 7 a. m. today. 

Frank Padikkala: Right. 

Sean Walker: This couch is getting real comfortable. Dog. No 

Frank Padikkala: Ha, ha, ha, ha, ha, ha, ha. 

Andy Leviss: Um, so actually that comment you made there sort of leads to one of the next questions that I had on our list to go with, which is the other stuff cohabitating with Dante, because there's, you kind of, it kind of tends to be two schools of thoughts that I run into in the wild is one is like the, well, it says it works with everything, just like throw it all together on the same network. 

And then there's the other extreme of the, I have major trust issues, Dante gets Dante and nothing else. And I imagine the reality is kind of somewhere in the middle. 

Frank Padikkala: Exactly. Absolutely. And so that's, that's the challenge, right? Uh, we have all these different transport protocols, mechanisms running around, uh, both on the audio and the video side, right? So, uh, Dante, because of its very, uh, popular deployments and, you know, we have more than 5, 000 products that are Dante enabled, uh, a couple millions, uh, in terms of the install base. 

So there's lots of Dante happening, but that doesn't prevent people from also having, say, AES67 on their network or NDI or, you know, any number of protocols and platforms running on the same network. I think, to your point, you're absolutely right. It is, you know, Finding that middle ground in terms of your design architecture. 

A lot of times where these deployments fail is the lack of understanding of what you're Devices are doing on the network, right? You don't know what it's doing on the network. And we almost assume that there's somebody else out there that should know the answers to that, right? I'm an Audinate representative, so I'm going to get on this call and I'll be like, yeah, I mean, you can put, you know, Dante Devices, it should work just fine, right? 

But I don't have visibility into the other things that you're putting on your network. You know what's going on there, but you then get on another call and talk to the representative from another organization and they're like, yeah, absolutely. You can put those devices on there, they're just fine, right? 

So you've had like four different manufacturers, standards, platforms tell you, yeah, you can have them all together, right? And to a certain extent, Network protocols, they do work together. It's not like it's gonna crash almost immediately. Although there are some, uh, that, you know, there are exceptions to that. 

But in general, there is a large number of things that can interrupt just fine. If you want your optimal performance, and what happens is, change. In your setup is what triggers a lot of these things, right? So, how many times have you heard, it was working fine until yesterday, and then someone brought this mixer in, and they just plugged it in, and now I can't do anything on the network, right? 

It's like, and you go in, your Dante controller seems fine, but And that's the problem with a lot of these, uh, you know, devices on the network because they're putting out information on the network. So it goes back to planning your network and establishing what you think is the best way to approach it. 

Now, I'm a security professional, right? So at my core, I'm I'm all about segregating traffic. I'm absolutely about segregating things, right? And again, you'll have different schools of thought, but I will always be on the other end of it when you say, if there is no reason to put the traffic together, don't do it. 

Put it separate. It's just fine. And that's why you don't even have to change switches. We're not asking you to purchase new switches. You need to have, you know, The skills to set up something as simple as a VLAN on a, on a network switch. And most network switch manufacturers today have some form of VLAN. 

So you're not entering in lines of code. If that's your barrier, you can go into your GUIs. Some are even color coded and super, like, people like Netgear, for example, their, their, their GUIs are, it's intuitive. You know that, all right, well, I mean, I'll, you know, shout out to Netgear because, like, they've actually even created profiles to say, all right, this particular network segregation will have this profile. 

So it's only Dante devices here, and it's only this device is there. And so they have, like, The profiles. That's a good way of approaching it. Now, the reason why that's there is that each type of network traffic has some form of underlying port protocol requirements that needs to be met, and one may not be, may be counterintuitive to the other one, which is where these things start piling up, right? 

So. I'm all about segregation. If you have the ability to segregate things, please do so. I think it keeps things much simpler. Because that's the whole point of a network, right? Uh, imagine you go to a doctor. And you tell them, I have a cold, my back hurts, my knees hurt, my eyes are twitchy, and I can't hear things, right? 

You've just given them multiple things, and if they 

Sean Walker: bro. I told you that in confidence. Seriously, what? Really? You gonna just call me out like that right now? Come on, dude. I thought we were, we hit it off so well earlier. Come on, man. 

Frank Padikkala: I thought we were friends, 

Sean Walker: Yeah, dude. Seriously, that's it. You know what? I'm canceling our dinner plans. That's fine. 

Frank Padikkala: Oh no. But yeah, see, look, Sean, I could give you like 16 different pills, 

Sean Walker: yeah. 

Frank Padikkala: Right? 

Sean Walker: Totally. 

Frank Padikkala: that would help and then we'd be friends again. 

Sean Walker: Oh, nice. Okay, great. 

Frank Padikkala: but you don't know which pill worked where, right? So then, after taking all 16 of them, what do you do? Process of elimination? That's horrible. You know, which is why, you know, unless your doctor is not located at the corner of a street, they will always start you off on something basic and build towards the next thing. 

I think the same simple process should apply to your networks. Keep things separate. There's no need to put things together. It's something as simple as, uh, a nice little network segregation that can solve all your things. There you go. 

Sean Walker: Sweet. 

Andy Leviss: So, and while on the subject, we should probably touch on the one thing that I know I see lots of people try and just do as a VLAN that I don't know your official policy. I know I generally advise against is make your secondary a separate switch. 

Frank Padikkala: Well, see, that's the thing. The secondary is supposed to be a backup network, right? Uh, it kind of defeats the purpose if you're putting it on the same switch. Because, like, you're trying to eliminate points of failure, and if the switch fails, You've lost both networks. It doesn't matter how much you've segregated them. 

It's like, so redundancy is about, you know, multi stacking things, right? You can't have things running on the same pathway and say they're truly redundant, 

Sean Walker: It's about bringing twice as much shit to the gig, bro. 

Frank Padikkala: Exactly. 

Sean Walker: That's what it's about. 

Frank Padikkala: Exactly. 

Sean Walker: twice as much shit so that you can look like you know what you're doing to the client. 

Frank Padikkala: looking at it. Yeah. 

Andy Leviss: Hey, look, if that gets somebody to do it instead of a VLAN, I'm not going to be picky about the reason as long as they're ending up in the right place. 

Sean Walker: But, but, but I think what you're talking about is You know, two completely separate networks, right? That then have their appropriate VLANs in them so that you can, you know, navigate the traffic. And for us, non network engineers, our VLANs kind of like lanes down the freeway where you're like, Hey man, you're going down this lane and you're going down this lane. 

It keeps them divided up. 

Frank Padikkala: Yep, that's exactly what it is. It's, uh, that's as simple as, you know, I can't think of a more simple way to, uh, explain that. 

Sean Walker: And so when you want to, 

Frank Padikkala: I'll call out Uh, and from a network perspective, we sometimes use the terms subnet and VLAN interoperably. They are not, they're two different things, just so we know. 

Uh, subnets exist at layer 3. Uh, so it's basically your networking, your IP addressing, that's, that's what a subnet is, that's one way of segregating traffic. VLANs are a layer two functionality, so it's essentially associating a port or a group of ports to a particular, uh, virtual LAN. Essentially like building a switch within a switch, right? 

Uh, you can actually have multiple subnets on the same VLAN. you Uh, not good practice, but there's nothing stopping you from saying I want to put a 192. 168. 1. 0 Uh, and, uh, 10. 10. 20. whatever on the same VLAN. You can do that, uh, but again, the isolation doesn't really happen because when traffic starts getting broadcasted, uh, it is within the same domain, uh, in a VLAN, right? 

So, uh, ideal way of doing it is VLAN and subnet have a separate one. Uh, and so when it gets into Layer 3, there is routing that happens if you need to go from one to the other, right? So we're talking about Dante, um, still being on the same subnet, being on the same VLAN, you have multiple switches, but they're still able to talk to each other. 

You can actually even have Dante, uh, On multiple, uh, subnets or multiple VLANs. You can actually segregate your Dante, but that's where things like, you know, Dante Domain Manager and our server platform helps you navigate that and the routing. The routing still happens at your Layer 3 switch, but you need a software tool to kind of talk to them, but to your point, yes, uh, uh, the simple way of thinking about it is, like, keep things as segregated as possible. 

Uh, that way your, you know, your, your service and your troubleshooting is much more manageable. 

Sean Walker: Okay, so when you say as segregated as possible in, let's put that into the context of your average audio human that is doing this, right? Because there's, you very quickly run up against what can an audio human stack into their knowledge base about networking, and then what does a networking engineer know, right? 

And those are very different things. Like, how much do I need to know to get through a corporate show with, you know, Yamaha consoles and Axiant wireless or whatever, right? And then, what do I need to know to, you know, go tell Cisco they're doing it wrong? Those are very different people, 

Frank Padikkala: I agree. I agree. I think, yeah, go ahead. Sorry. 

Sean Walker: no, no, no, no, but, uh, so how much segregation would you expect or hope or, uh, want for your average or, you know, one step above average audio human to know? 

Are you thinking like, Okay, you've got this Dante network with your, let's call it the usual suspects of people that would be on that in an, in an audio environment. And you're saying like, okay, cool. You're, your console's like 192. 168. 0. 1. And you're, you know, you're then wireless is maybe 192. 168. 1. 1. And you know, I mean, you kind of do it out like that. 

Or are you saying like the, You need to VLAN out the switch so that wireless is on these ports and Dante is on these ports and you know How much segregation are you are you hoping for 

Frank Padikkala: good, good, good question. Uh, I mean, ideally you keep the Dante environment, uh, within itself. So if there's Dante traffic, uh, you know, just keep it, uh, uh, within the same, same VLAN. Um, easy to assign your IP addressing, do something similar as far as the, the secondary is concerned. If there is a secondary, Uh, and then basically have that, uh, for Dante traffic, and then, um, open up the rest of the switch for other control, uh, wireless, whatever type of communication that you'd expect on there. 

That way, um, you know, it's, it's pretty simple, and the biggest advantage of that is that when you have, uh, things locked down to that level. You don't expect devices to just because you got to understand like corporate events, live events, you're looking at a ton of different people and it's, it's fast paced and things are moving and you don't want something as simple as plugging in a network switch to be the end of your, your show. 

You know, that's it. That's what happens though, right? You know, 

Sean Walker: I mean, that's an everybody's fired scenario right there, right? Like, 

Frank Padikkala: yes. And, and here's the sad part about it. I have been part of deployments, and this is on the enterprise side, right? So you're looking at live events, you're still looking at a finite number of switches. I've been to data centers that have been taken down. 

by our AV professionals because they plugged the wrong AV device into the wrong port. Something as simple as that. I've even been, I will not name names here, part of incidents where security came in and they thought there was some kind of, uh, uh, a hack happening and, you know, it's like security officers and step away from the network port, put that device down kind of thing that happens all because somebody plugged it into the wrong port, right? 

And All of this points to the need for having better network practices. So you don't need to overcomplicate it. I mean, again, as I say this, I don't want to put the fear of God into people saying, Oh no, I'm never going to do anything network because of this. No, it's absolutely doable. Something as simple as spending six to eight hours on our Dante Level 1, 2, 3 certifications is more than enough to give you absolute freedom. 

A handy amount of information to manage your own networks in a live events type of scenario, right? And what that does also is give you the language, like you asked Sean, to talk to Cisco and talk to your network engineers and be like, Hey, I've done this already. It works on my end. It's not me. You need to look into it. 

And that's usually the biggest challenge that we have, right? We go in with blanket statements like, I don't know, it seems to work fine when I did it, but put it on your network and it doesn't work. And there's no network engineer out there that wants to take the effort to troubleshoot that for you. You need to understand your network enough to tell them, This is what I did. 

This is what works and this is what doesn't work. Give them the symptoms better and they should be able to give you more help. I've practically built a career on this, right? This is what I do. Every call that I get into, I go in and I be that little translator who says, look, this is what's happening. This is what we tried. 

It doesn't work. And you give the right amount of information. Networking people all of a sudden seem friendlier, right? But instead we go like, yeah, I just want an AV VLAN. And can you put everything on the AV VLAN? And, and they're like, what are you even asking for, bro? That makes no sense. Right? Uh, so, so, 

Sean Walker: weird to me right now? 

Frank Padikkala: you know, so I have a little bit more information. I think it, it simplifies the process. Standard. 

Sean Walker: Sure, sure. Okay, the 

Frank Padikkala: Mm 

Sean Walker: I'm the lowest common denominator guy in case you weren't sure. Andy's the smart one I'm the one that just asked the question so the rest of the world can understand Alright, so you've got, let's say like, uh, you know, let's go back to your kind of bog standard corporate show. You've got a Dante enabled console in front of the house, you've got some Dante enabled, I keep wanting to call them Rios, but you know, they could be anything with Dante enabled snake system, right? 

Uh, and, uh, Probably a pair of switches at front of house so you can do controller and virtual playback and QLAB and whatever else you got, right? And then, uh, you've got wireless on the other end and A2 LAN. How are you feeling like the best way to configure that would be? Because that's a pretty, I would say, reasonably simple, standard, like, that's kind of everybody's bread and butter is You know, they got, you know, some sort of a QLCL, Rios, Axeant, you know what I mean? 

And I'm not trying to promote those, just that that's the, that's the reality we live in, right? Like that's where it's at. So what's, what is your, you know, best case scenario in, in that to make it all play happy? Because you're also gonna have amp control, right? Network manager or RD Net or, you know, R1 or whatever flying around someplace. 

And to be able to pull as few cables as possible, You know, if you've got redundant networks, what's your thought on how to make those all play happy and nice and, and, uh, be rock solid reliable like it all says on the tin when you're not saying, calling nine manufacturers going, of course they'll play together, right? 

Frank Padikkala: Yeah, I agree. I think the scenarios that you're talking about is just about having a little bit of effort into planning these things and maybe even pre configuring some of the networks on your devices, right? So that you're not putting, just plugging things into a switch. If you have ownership of the devices that you're playing with and there's a way to control it, part of your pre setup process, ideally, is a list of devices. 

Uh, what's being put on the network. And now in those control type traffic scenarios, I don't envision anything that could disrupt the network to the point where things don't flow, right? So that's, it is pretty simple. Uh, if you have a secondary, just make sure that there are different networks. Um, so, to set the primary up a static, if that's easy for you, you know, it was like, cause sometimes like DHCP involves, uh, And, uh, that's always a, if you're bringing in your own devices and you're creating your own network for this environment, you may or may not have that level of IT backbone there. 

You know, and again, that's not a heavy backbone, so to speak. You can go all fancy and even have like a, you know, a, a, a little You know, NUC or something that can function as your DHCP server, giving out the IP addressing and all that stuff. But instead, I think the simplest way to do it is probably having manual IP set, uh, set them, plug them in. 

Uh, I think a good practice also is building out these things, you know, visually in documentation prior to doing that. That's where a lot of these things can fail, right? So, again The network can handle this. There's nothing in any of these things that's alarming if you've planned it out. So, have a list of devices, have a list of IP addresses, put the port assignments, and most importantly, label your cables, you know what I'm saying? 

And plug them in right, 

Sean Walker: Woah, are you saying that I still have to label my cables and networking like I 

Frank Padikkala: Yes, you do. Yes, 

Sean Walker: the fuck, man? I thought I was over all that. Come on, you're killing me, 

Andy Leviss: we got, we got it down to one label instead of like, you know, 56, so. 

Frank Padikkala: And hey, like, so, you know, fun, fun fact out there, there are Switch manufacturers, I think it's, uh, Ubiquity, who has like, they have their newer ports, uh, that have like augmented reality in them. So you can actually download an app and you can, you know, turn on the camera and move it in front of your Switch and it'll light up the port that you're looking at and give you all the information, like. 

This is the IP address. This is the stuff on it. So it's like, you know, I think it'll get easier, you know, labeling requirements may become better with AI and stuff, uh, down the line, but you know, it's, 

Sean Walker: sounds like a thousand bucks of pork I can't bill my client for. I think I'm good, man. Like, 

Frank Padikkala: probably right. 

Sean Walker: I think I'm good. Maybe somebody else has played in that league, but that's not the league I'm batting in, bro. 

Frank Padikkala: I agree. 

Andy Leviss: I'm gonna throw out a pro tip here as we're talking about like keeping a sheet of all the IP addresses that, uh, Donny Koozer, a good friend of his, he does the sound based RF coordination software, but he's also the head of, uh, PWS's New York office and one thing he's started doing on all their racks is the front of every rack has a QR code. 

That takes you right to a web browser to a read only link of a Google Sheet that's got every IP 

Frank Padikkala: That is such, that is such a simple yet effective way of doing it. 

Sean Walker: Man, 

Frank Padikkala: that. 

Andy Leviss: it's, it's really easy, you know, there's tons of QR code generators online and you just do it as a Google Sheet, copy that URL in, print that out on a label and stick it on every rack on the front of every network switch and it just makes everybody's life 

Sean Walker: what a simple but genius idea. What a huge flex, dude. That's 

Frank Padikkala: Yeah, I know, and a simple, I love the idea, it's like a read only sheet, you know, perfect. That's, that's, see, but that's what you need to do. You need to know what you're being, uh, what's being put on the network, how they're, how things are plugged in, and most errors, unfortunately, have probably nothing to do with Dante or, or even the switch. 

It's just because, you know, we're not sure what we're doing and, you know, we plugged in something where we shouldn't and that's, that's how it starts. 

Sean Walker: I can say from decades of personal experience, the only Dante failures we've ever had in our entire company have been . Oh no, I did a dumb, dumb, it has never been Dante's fault. You know what I mean? And I'm not saying that just 'cause you're sitting here, like every, every one of 'em has either been a, a physical connector where I, I, I, or we bought cheap connectors and we're like, well that's broken. 

Like anything else could have been. Or you plugged it in and went, oh, I did a dumb dumb, and this is in static and should be A-D-H-C-P or the other way around. 

Frank Padikkala: Yep. 

Sean Walker: it's on the wrong, you 

Andy Leviss: I think, is that what sports ball people call an unforced error? 

Sean Walker: For sure. Yeah, totally. Um, okay. One more question about that and then I'll get back to my other train of thought cause it's early here. Uh, are you finding that the most common problems are that people have over complicated their network trying to get too crazy with it or put too much stuff on it? 

Frank Padikkala: I see, that's a very good point, and I'll lean into some of my design engineer on the commercial side experience to respond to that, because it's funny you say that. I don't think a lot of overcomplication happens at the get go. I think what happens is because it's the network, there is the assumption that, oh yeah, it's a network, all I have to do is just, you You know, buy another patch cable and then just put it on there, right? 

So it, it always starts off pretty simple, but over the years, what happens is we hierarchically make our networks more, it's not even trying to make it complicated. It's just, we're trying to do much more than it can, right? So this is where it's important to have documentation and a little bit of planning as to what's happening. 

Something as simple as, and again, A lot of these challenges are probably, uh, negligible to manageable as far as the audio is concerned, but you add networked video into the mix, which, in which each video uplink of a higher quality can easily saturate a one gig link, you are now looking at a ton of traffic being put onto the switch, and it starts affecting the audio, it starts affecting the control, it starts affecting everything on there, Uh, and it's because you've not necessarily planned for the, uh, for the network deployment. 

So I think, uh, maintaining regularly updated documents is probably the best way to approach it, uh, understanding your switch features. And at some point we come into that ugly word in networking, QoS, which is absolutely necessary. Uh, when there's a lot of traffic on there. It becomes important to prioritize some traffic over the others. 

Dante, for example, leverages PTP as its clock mechanism. So if you don't have PTP prioritized, Things fall out of whack. And the reason is, there is no compression in Dante Audio. It's uncompressed audio. Uh, you need something to say, this packet was supposed to arrive at this time, this packet was supposed to arrive at this time. 

You need that clocking mechanism. And so it's important to prioritize certain type of traffics. But that's more relevant as you start saturating and, you know, overcrowding your network. So, progressively As you keep adding things, understand what, uh, your device is doing. A simple way of, and here's my recommendation to anyone who is planning on putting media, audio or video on the network, a simple rule of thumb is whatever device you plug into a network port, please know what it's doing to your network. 

Right? It's a simple question. And you might not know the answer to that. And that's exactly where you need to go back to your manufacturer partners or platforms like us and say, Hey, Audinate, can you tell us what you're doing on the network? What is this device doing to my network? And we are supposed to give you easy, easy, Accessible documentation that you can reference, not a 60 page white paper that details that, that's, we do have that as well, but for the sake of simplicity, you need to know what each device does to your network. 

Very simple. And I think that kind of helps you architect better solutions and prevent the overcomplication of things, which almost always is a progressive overcomplication and not, uh, not from the get go, right? So, uh, excellent question, though. I love that question. 

Sean Walker: Totally. So if we go back to our bog standard corporate show we were talking about before, which is, you know, in audio, kind of your bread and butter use case scenario, if I, if I don't, you know, if I'm not speaking out of turn here, uh, how would you recommend that to be set up or laid out for the, for those that are Bye. 

You know, of differing opinions, or maybe, maybe don't know, or maybe got some bad advice, or like, what's your thought about how to take that, you know, single console, maybe a couple of stage boxes of whatever, some wireless and some amp control for their system, uh, how would you lay that out, or what, what's the best practices to lay that out, I guess is maybe a better 

Frank Padikkala: Oh, uh, good question. I mean, it depends on how you want to, uh, how you want to transport and how much of a network switching architecture you want to maintain. Um, if the deployment is as simple as that, and you're only looking at 20 to 30 or maybe 40 devices that can all be within one switch, I think just dedicating a single switch for Dante is probably the simplest way to do it and prevents the most number of errors. 

That way you're not, you're not even looking at any of the other things, right? So you can have another switch where the control traffic can do, uh, and you know, um, you can get a little creative if you want things to overlap or go from one switch to the other or you have particular things, uh, there's tons of ways that you can manage your traffic, uh, but. 

If for the sake of simplicity, sometimes just keeping things as separate as possible is probably the best way to do it. Now, that's that being said, this is the network we're talking about, right? It all depends on what you're trying to accomplish in an environment like a corporate event, like the one you said, where things are set up, event happens, it's successful and done, you tear up and you're, you're leaving, right? 

Those are not fixed installs. So, there is no need for constant monitoring. Uh, there is no need for managing these devices. You have to manage them on, you know, remotely or you're taking them back to your warehouse or your storage location and it goes back to a setup somewhere, right? So, in those kind of situations, almost having like a dedicated set of switches that are, uh, managed switches that have Dante profiles on them that say, It's kind of, you've configured the switch to say this switch can handle Dante traffic and having a bunch of them to do that. 

Uh, it's probably the simplest way to do it because again, in that scenario, you don't really need to leverage the entire power of the network and you know, the monitoring and like global environments. You don't really need that. Right? So if you want to keep things simple, keep it simple that way. Now, if you go into more complex environments, where there's a fixed install piece to it, or you're leveraging into a corporate environment, that's where some of our software tools may also come in handy. 

Now, uh, just so you know, there are also, you know, Dante devices that function as bridging devices. So, uh, a lot of folks carry bridging devices as part of their equipment list, which, in which what'll happen is you'll have a customer who has certain high quality things that they want to incorporate into your production, right? 

So the way they do it What they would do is they would actually build, they have a Dante network and they'll be like, Hey, can you use my Dante enabled microphone as one of the sources into your thing? And you'd be like, well, it's my Dante network. I don't want to put your Dante network on mine and mix up the whole thing. 

Right? In those scenarios, there are devices. that have multiple Dante cards on them. You put one on your network and the other one on the other network, and you essentially create that bridge, right? Uh, so having a couple of, uh, bridging devices, uh, probably slightly more expensive than, you know, the other Dante devices, but it's, it's worth having it if you're running into, uh, on, uh, on location things more frequently and you need to incorporate them. 

If not, then, uh, Keep it yourself, keep it within your own switch environments and keep it simple and separate. Right. Uh, have switches dedicated for with, with Dante profiles and you know, enabling all the traffic that makes Dante successful. Uh, and you know, you can even go to the point of simplifying this to other texts where you say, if there are. 

30 devices, use this. If you're running into 60 devices, use this and this. This is how you plug it in. You can actually hierarchically plan out your network to the point where it becomes real plug and play. But what that would mean is you need to do a little bit of network design and a little bit of architecture planning as to how Things get plugged up and how our, uh, how the transport happens before the event, right? 

If you do it at the event, then that becomes a little bit, because, see, the difference between troubleshooting audio and troubleshooting the network is it's visible, it's auditory, you know when your audio isn't functioning, but When your network goes wrong, you now have to put in, you know, uh, you're scanning for IPs, you're looking at Dante Controller, you're using your software tools if you need it, and you know, it's a different type of troubleshooting that you probably don't want to do. 

So, keeping things tested. And documented prior to events is, I think, in my, uh, in my opinion, the best way to build out successful events as opposed to doing things on site with the network, you know, don't do things on site with the network and don't do switch, don't, don't change switch configs, don't factory reset a switch, you know, um, 

Sean Walker: they take forever to restart. Why would you do that on a job site? 

Frank Padikkala: yeah, well, yeah, I mean, 

Sean Walker: But I get you, as you were saying. 

Andy Leviss: and flailing. 

Sean Walker: Yeah, right? Totally. Okay, so, we've got our bog standard corporate show. We've got our switches that we've got control of. We've got, we've followed the Audit 8 protocols to program our you know, bog standard, everybody's had them, you know, SBCVS 250, 350 kind of switches that are like literally the document you can find everywhere. 

How would you design that network then for our, you know, I'm asking questions for our listener. because some of them have not done it yet, right? How would you think about designing that so that you've got your console, your stage box, your amp control, they just want to pull a pair of cat cables or maybe they're turning it into fiber and how do you design that network, uh, as it's, you know, IP infrastructure or it's VLANs or what are your thoughts, what are you thinking when you see something like that going, okay, here's how I'm going to make this work, here's how I'm going to get Dante and control and the wireless control so that somebody can have. 

You know, they can pull one set of cables instead of a bunch of cables and different switches. And you got, you know, a pair of switches in front of the house so that you can get Dante controller in and you've got a pair of switches, same switches at A2 LAN so you can get all your Rios and wireless and stuff on. 

What are your thoughts about IP scheming and that kind of thing? 

Frank Padikkala: Yeah. I mean, look at the number of devices and, uh, if you're set, I guess the first step is determining the switches. Always have managed switches, uh, which means don't buy off the shelf switches that you get in, you know, X, Y, Z, 

Sean Walker: My GS308 isn't going to work for this, huh? 

Frank Padikkala: Uh, yeah. 

Sean Walker: Yeah, so, so let's say you've got your, your switches you need, you know what I mean? Like CVS 350s or 250s or something that are programmed according to the manual, right? And then are you leaving everything in, in link local or DHCP and letting it just find itself if 

Frank Padikkala: I would say 

Sean Walker: or less? 

Frank Padikkala: if you do anticipate having control traffic on there, it's always better to have, uh, IP addressing associated with your devices. Uh, at a minimum, I'm a huge proponent of probably putting in manual IP addressing because that's easier than, uh, BlinkLocal works just fine. Uh, but usually it's a Dante only environment, but here you have a little bit of control and you need, because it, it depends, right? 

There are some devices that also leverage the same network port for their control traffic, right? So you don't have multiple network ports on there. Uh, and that's perfectly fine because Again, at that communication level, this is a port to port kind of thing, so when you open up the software that is the control piece, it is still talking to the same port, so in those scenarios, you are actually having to put things on the same, you know, same network. 

You have, you don't have a ton of options in terms of segregating things. It's easier to manage if you have, uh, an IP address set. Take, uh, an IP address range that can hold enough devices so you, if you're, you know, if it's like a, uh, slash 24 environment, you can go up to 254, uh, devices, 253 devices, uh, and that, that kind of suffices in terms of, uh, IP address scheming, uh, so, uh, Switches are reliable. 

Uh, you know, your network cabling, you have your IP addressing scheme that's already set up into your devices. And at that point, it should be fairly plug and play. Uh, now things do get complicated if some of those devices, which you are seeing. So let's go to the future too here, right? It's like, let's go down the line what's happening. 

A lot of devices have requirements in terms of accessing the internet for some reason, or they need, uh, something of that sort that happens. That's where. 

Sean Walker: not on my Dante network, but that's fine. If you want to get crazy, that's cool. Do that. Yeah. 

Frank Padikkala: yes, good. I like the way you said that. When you say, not on my Dante network, that's the call that you have to make. That you have to tell and pick devices that are, yes, this is what it is, right? Now, there is no harm in putting things on the internet. Let me just say that there. If the network is designed right, if the routing is established, if things are manageable, uh, there's no problems in, in, uh, I'm not a big fan of giving internet access because a lot of different devices like a switch for example, you can set a route there that says like, this is the gateway of last resort. 

You know, if you don't know what's going, this is how it goes out into the internet and you're not looking at a ton of traffic. There's, there's ways to configure those two efficiently, so there shouldn't be any fear factor associated with it. But if your comfort level says no, I prefer not to have internet devices or things that need access to the internet on my network. 

Perfectly fine. But when you do need them, and that happens, again, this is where incrementally you need to kind of start dwelling into more and more on the networking side of things and how things function on the network. Um, it's, it's a good idea. I think for anyone trying to build a future, uh, in this thing, because down the line you're going to, you're, you're also, so let's look at the future and it's not the future. 

It's maybe the future for some, but a lot of people do it today. There's a ton of cloud based mixing happening. There's a ton of cloud based audio happening. There's a lot of cloud transport happening. And usually in those scenarios, you have people who are responsible for the network and the cloud part of it. 

And then you have, um, you know, people who are dealing with the audio and keeping sticking to their, Traditional strength. So, uh, this year at NAB, um, uh, I did a couple of interviews and one of the things I did say is that I feel that the audio engineer of the future is also a network engineer, is also a cloud engineer. 

You know, they have some skills. Again, they might not be able to build out an entire network themselves or architect a corporate enterprise environment, but they have enough information to be, I don't like saying enough information to be dangerous because that means you're going to mess something up. 

You're not being dangerous. You're, you know exactly what your strengths are. You're an audio professional, but you know enough about your network to be able to do that. There shouldn't be that fear because networks are built to handle all of this. In your case, keeping things simple, manage your switches, keep your IP addressing scheme. 

Um, and it should function just fine. You're not looking at anything that will necessarily invalidate or break your network connection. It's only when, you know, you start dealing with a lot of traffic and, you know, it's saturating your connections and, uh, and again, this is not a Dante problem at all. Uh, I think the bigger culprit in most of these things is video, because video takes up a ton more band, bandwidth, but in audio type environments, this, uh, it should be fine. 

And even like, compressed video, uh, that we're using, say, for, you know, Zoom or whatever, stuff like that, that's also low bandwidth. It's only when you have like, higher quality AV over IP, video over IP type things, where you're trying to use the network to transport the video, that's when things get a little iffy. 

But in your scenario This should be perfectly fine. There shouldn't be any issues designing that. Good documentation, manage your switches, manage your devices, upgrade your firmwares, uh, when needed, not during the show, but do them, uh, because that's another part of being a network device. Unfortunately, every now and then your device needs to be upgraded, uh, with all the functionality, the security, and things that are, Rolling out. 

We do recommend having that. Follow your manufacturer's guidelines. That's not an ordinary thing, but follow your manufacturer's guidelines for that. Uh, maintain a, uh, a document, uh, uh, a primary document that says, this is my device. This is, it's IP that I associated with it. This is the firmware version. 

This is the back address. And typically this goes on this switch with this port. You know, detail it as much as you want, but come up with a workflow for managing these things. Usually, it goes wrong because we don't plan any of this stuff, and we just go in and say, Yeah, it should work, right? Let's just plug everything together. 

And it doesn't work. And when it doesn't work, you don't know what went wrong. 

Sean Walker: Totally. See, Andy, there it is, right from the horse's mouth. Don't let video get near your frickin network. Those guys mess up everything, dude. It's always video's fault. 

Frank Padikkala: I feel like I'm in a press conference where I don't know what I'm saying is going to be twisted and used in whatever way, but you know what? I'll take my chances. 

Andy Leviss: So I know 

Sean Walker: at all. 

Frank Padikkala: live this life. I'm perfectly fine with that. 

Andy Leviss: I know we're, we're, we're coming up on time. I want to lightning round one more question at you. Preferred Leader. This is, again, a thing that gets into religious arguments, I think, because my view and my understanding is basically like, if you need to use it for reasons of like, I need to clock to some source that's not Dante, use it. 

Is there any reason or any benefit or is there any detriment to using it in other circumstances where I don't need it for that reason? 

Frank Padikkala: You can use the preferred leader if you know that the quality is Let me just explain that a little bit, right? So the clocking process follows what's called BMCA, which means Best Master Clock Algorithm, which is not like, it's not, it's a standard. It's an industry standard. And basically what it does is that when there are multiple devices that are capable of becoming clock leaders, uh, And so that's a good point to remember. 

So before I go into that, after, you know, listeners, please go to our website on our FAQ page. There's actually a detailed description of what device is capable of becoming a clock leader, what devices have that capability, uh, because this is a, uh, you know, uh, there's PTP V1, V2, there's, there's stuff happening there, right? 

So there is a clock election process that essentially determines which device is going to assume the responsibility of the clock leader. What happens is that is based on a couple of different things. MAC addresses, the quality of the clock, you know, there's a, there's a, there's a hierarchy how that is decided. 

And usually it just, it's just fine. And one device assumes the responsibility of clock leader. Now, a good scenario for having a preferred leader is when you have two devices that may potentially have the same, Clock structure, and same, you know, high quality clock behind it. Similar MAC addresses and things like that. 

So the tiebreaker becomes a little bit of a challenge. So, if you set one of them up as your preferred leader A good idea is to have the device that would be the first to go on and the last to go off as your preferred leader. Because when a new device is introduced, you don't want the re election process redefining the clock to say, oh wait, I found a better clock, let me just re clock to that one. 

And that's what happens, right? Usually what you'll do is you'll plug your devices in, things are fine, and then like a couple hours into your testing and, you know, 30 minutes before the show, somebody comes up and says, Oh, oh, oh, I need to add this device on there, uh, because we really need it. And you're like, okay, sure, it's just Dante, I'll plug it in. 

But that plugging it in causes a re election process and a little bit of disruption and you don't want that happening, right? So, 

Sean Walker: like your, in our bog standard corporate show example, something like your console is a good place to start 

Frank Padikkala: yes, it's, it's, it's, consoles usually have, uh, a simple rule of thumb is any device that are higher channel count, uh, and, uh, you know, higher quality chipset implementation behind it, uh, like our Brooklins, our Broadways, our, um, our Ultras, you know, all those higher quality chipsets are usually a good way of, uh, You know, assigning that responsibility because they can clock, uh, at a higher level. 

Um, so yes, a console is a good place to set that up. Uh, and, it's, and again, there is no need to have a preferred leader if you don't envision changes happening, but things can go wrong, things can go off. 

Sean Walker: It's life, bro. Changes happen. 

Frank Padikkala: It is life. 

Sean Walker: Yeah. 

Frank Padikkala: is life. So, you know, set it up, uh, but, uh, Andy, to your question, that's a, that's good, there are sometimes external, uh, sources associated with it. 

So having a preferred leader, having the sync to external enabled may be a practice that is needed on your particular environment, but usually, uh, the clock election process, you know, I know I described this in detail, but do understand in reality, all of this that I described happens in milliseconds. 

It's like, that's how fast it just, it just happens really quick. Right? So it's not like it's a, it's a big thing that changes the architecture and then you have to configure and reconfigure things. Um, yeah. What is needed is, you know, an understanding of which device, if you have a preferred device that you would like to have as your leader, that's what that, that's there for, you know, it gives it that priority. 

Andy Leviss: Right on. Well, and that, that talk about clocking makes me look back the clock and realize we're all getting about time that we gotta let you go and I gotta get off on that vacation. 

Sean Walker: Yeah, buddy. 

Andy Leviss: uh, yeah, but I mean, thanks for spending this hour with us. I think, I think we had a lot of stuff that'll help some folks out here. 

Frank Padikkala: I hope so. I hope so. It was like, I have, I, I've, I've, you know, I've listened to several of your episodes and I know the conversations are very live events focused and, you know, people who are in the trenches every day dealing with these kinds of things. I think what I would like to reemphasize is that there is no need to fear the network. 

It is there to help you. It simplifies things. Invest into it a little bit in terms of your training, your education. We have all of that. Check out our website, our Level 1, 2, 3 certifications. Tons of those. Go in for them, learn them, and obviously reach out if you have any questions. That's what we're here for. 

There's a lot of research out there, 

Andy Leviss: I was gonna say the, the biggest thing I'll throw out there too is reach out to y'all on support. Like, you've got some great, really smart, really helpful folks working for you. And, conversely, there are lots of folks on user groups online and on Facebook that really, really think they know what they're talking about and don't. 

So when all else fails, reach out to Audinate. They'll help you out. They're 

Frank Padikkala: Yeah, for sure. I mean, again, the forums are fantastic. We like to read through them too. People have built up tons of expertise on Dante over the years, right? So there are great, very smart people out there. But you know, that's what we're here for. If you have any questions, always reach out. You know, nothing that a quick call or a quick email can't solve. 

Andy Leviss: Yeah, and I'll say I don't want to I don't want to throw user groups like that entirely under the bus I think the the issue is that the the internet is the big democratizer so You don't know there are people who will speak with expertise who actually have the expertise and there are people who will speak with Expertise that have no idea what they're talking about But talk like they do and it's a little hard to tell so it's always good to go back to the source when you can That's that's the former support tech in me 

Frank Padikkala: Yep, absolutely. And I think that's important because as we go forward, the expertise is kind of getting more and more diversified because in terms of like, yeah, in the past, you know, a little bit of the network, you're, you're an expert. Now you need to know cloud, you need to know this, you need to know that, you need to know software, you need to do, do virtualized stuff, right? 

And Automate plays in all of those areas. Like we do everything. So, you know, come to us. Well, I think we'll have good information for you. It's like, uh, that's what we're here for. 

Sean Walker: That's awesome. Thanks, Frank. Thanks for hanging out. Thanks to RCF and Allen and Heath for letting us yap constantly about audio nerd shit. That's the pod y'all. See you next week. 

Frank Padikkala: Love it.


Music: “Break Free” by Mike Green