Waarom tikkende audio soms meer zegt over topologie en switchkeuze dan over de AV‑hardware
Afgelopen week zat ik opnieuw aan tafel met een AV‑reseller voor een groter AV‑project. De aanleiding was herkenbaar: de eindgebruiker ervaarde storende tikkende audio, onbetrouwbaar gedrag en een systeem dat niet voldeed aan de verwachtingen.
De storingen bleven aanhouden en daarmee groeide ook de twijfel. De conclusie was door de eindgebruiker eigenlijk al snel getrokken:
“De AV‑hardware functioneert niet goed. Die moet vervangen worden.”
Op zich is dat een logische gedachte. Wanneer gebruikers tikken in de audio horen of merken dat een systeem niet stabiel reageert, gaat de aandacht bijna automatisch naar de zichtbare en tastbare onderdelen: microfoons, DSP’s, versterkers, encoders, decoders of andere AV‑apparatuur.
Vanuit die gedachte werd besloten het traject opnieuw aan te vliegen. Er werd een nieuwe AV‑reseller bij het project betrokken en een nieuw ontwerp gemaakt. Daarbij werd gekozen voor nieuwe hardware en moderne, IP‑gebaseerde oplossingen, geschikt voor high‑resolution video en kritische audio.
Tot zover niets ongewoons.
Maar toen kwam het gesprek op het netwerk.
En daar werd het interessant.
Speciaal aangelegd voor AV
Wat deze case extra opvallend maakte, was dat het netwerk geen oud of generiek kantoornetwerk was waarop later AV‑apparatuur was aangesloten.
Integendeel.
De netwerkbekabeling en switches waren nog niet zo lang geleden speciaal aangelegd voor de vorige AV‑installatie. Op papier zou je dus verwachten dat deze infrastructuur geschikt was voor wat het systeem moest doen.
En precies daar zit de valkuil.
Want een netwerk aanleggen voor AV betekent nog niet automatisch dat het netwerk ook goed ontworpen is voor AV‑over‑IP.
De vraag is namelijk niet alleen: ligt er een kabel?
De echte vraag is: klopt de topologie, klopt de switchkeuze en kan dit netwerk het AV‑verkeer betrouwbaar verwerken?
Het ontwerp onder de loep
Bij het analyseren van het bestaande netwerkontwerp werd al snel duidelijk waar de kwetsbaarheid zat.
Het netwerkdesign van de vorige AV‑installatie was namelijk geen Spine‑&‑Leaf‑structuur, maar opgezet als een daisy‑chain‑structuur, waarbij switches achter elkaar waren geschakeld.
Dat is een ontwerp dat je in klassieke IT‑netwerken nog regelmatig tegenkomt, maar in omgevingen met real‑time audio, multicast video en high‑resolution AV‑stromen steeds minder vergevingsgezind is.
Belangrijk detail: de gebruikte switches in het voorafgaande project waren helaas niet van NETGEAR en ook niet specifiek genoeg geselecteerd met dit type AV‑toepassing als uitgangspunt.
Zolang de belasting beperkt blijft, werkt zo’n ontwerp vaak ogenschijnlijk prima. Maar zodra meerdere audio‑ en videostromen gelijktijdig actief zijn, begint de topologie zelf een rol te spelen.
Niet altijd zichtbaar.
Niet altijd direct meetbaar.
Maar wel merkbaar.
En in dit geval zelfs hoorbaar.
Audio is genadeloos
Video kan soms nog wegkomen met een korte hapering. Een frame dat even overslaat of een lichte vertraging valt niet altijd meteen op.
Audio is anders.
Een kleine instabiliteit in het netwerk vertaalt zich direct naar iets wat iedereen hoort: een tik, een kraak of een korte onderbreking. En op dat moment voelt het voor de eindgebruiker niet als een netwerkprobleem.
Het voelt als een slecht AV‑systeem.
Dat verklaart ook waarom AV‑hardware zo vaak als eerste de schuld krijgt. Niet omdat die hardware daadwerkelijk de oorzaak is, maar omdat deze het probleem hoorbaar maakt.
De eindgebruiker hoort geen multicast‑issue.
Ziet geen topologieprobleem.
Denkt niet aan latency, jitter, buffering of uplink‑capaciteit.
De eindgebruiker hoort alleen tikken in de audio.
En dus lijkt het logisch om naar de AV‑oplossing te wijzen.
Nieuwe hardware, oud probleem
Wat mij in dit soort trajecten telkens opnieuw opvalt, is hoe snel nieuwe AV‑hardware wordt gezien als dé oplossing voor problemen die eigenlijk in de infrastructuur ontstaan.
Maar als de basis niet klopt, neem je het probleem gewoon mee naar de nieuwe situatie.
Sterker nog: moderne AV‑over‑IP‑oplossingen stellen vaak juist hogere eisen aan het netwerk. Hogere resoluties, meer gelijktijdige streams, real‑time audio en strakkere timing belasten de infrastructuur zwaarder dan eerdere systemen.
Nieuwe apparatuur vraagt dus niet minder van het netwerk.
Vaak vraagt het meer.
En dan wordt een ontwerp dat ooit logisch leek ineens de bottleneck van het hele systeem.
In deze case zat de kern niet in slechte AV‑hardware. En ook niet in oude bekabeling — het netwerk was immers speciaal voor AV aangelegd.
De uitdaging zat in de combinatie van:
- een daisy‑chain‑structuur
- de gekozen switches
- en zware, tijdkritische AV‑stromen
Dat maakt het geen productprobleem.
Dat maakt het een ontwerpprobleem.
Switchkeuze doet ertoe
Een switch die prima functioneert in een standaard datanetwerk, is niet automatisch geschikt voor elke AV‑over‑IP‑omgeving.
Dat heeft niet per se te maken met goed of slecht. Het draait om passendheid.
Hoe wordt multicast afgehandeld?
Is de configuratie geschikt voor real‑time verkeer?
Is er voldoende uplink‑capaciteit?
Wat gebeurt er als audio, video en control gelijktijdig door dezelfde netwerkpaden lopen?
In een daisy‑chain‑structuur worden die vragen extra belangrijk. Elk apparaat verderop in de keten is volledig afhankelijk van de schakels daarvoor. Eén overbelaste uplink kan invloed hebben op het hele systeem.
En dat maakt storingen verraderlijk.
Het werkt meestal prima — tot het druk wordt.
Tot alle bronnen actief zijn.
Tot het moment waarop het écht moet werken.
Wat ik jullie wil meegeven uit dit project
Wat ik jullie wil meegeven uit dit project, is dat we bij AV‑over‑IP verder moeten kijken dan alleen de apparatuur.
Een goed AV‑netwerk begint niet bij de vraag hoe we bestaande bekabeling zo slim mogelijk kunnen hergebruiken.
Het begint bij de vraag: wat heeft dit systeem nodig om betrouwbaar te functioneren?
Soms betekent dat extra kabels.
Soms een andere topologie.
Soms andere switches of een andere configuratie.
En soms vooral een eerlijk gesprek, vroeg in het project, over de grenzen van het ontwerp.
Dat gesprek is niet altijd makkelijk.
Maar het is altijd beter dan achteraf zoeken naar storingen die je met een andere infrastructuur waarschijnlijk had kunnen voorkomen.
Conclusie
De kern van het probleem in deze case zat niet in de AV‑hardware en ook niet in het feit dat het netwerk speciaal voor AV was aangelegd.
De kern zat in het gedachtengoed waarmee het netwerk was ontworpen.
Het netwerk was opgezet vanuit klassiek IT‑denken: efficiënt gebruik van bekabeling, flexibiliteit en de acceptatie van buffering en latency. Dat werkt uitstekend voor dataverkeer, maar schuurt zodra je real‑time audio en video over datzelfde netwerk gaat sturen.
AV‑over‑IP vraagt om een ander vertrekpunt.
Niet: hoe passen we AV in een IT‑netwerk,
maar: welk netwerkontwerp heeft AV nodig om voorspelbaar en storingsvrij te functioneren.
Zolang AV‑netwerken worden ontworpen met IT‑logica als fundament, zullen problemen zich blijven manifesteren waar AV het meest gevoelig is: in de audio en video.
Ik ben benieuwd hoe anderen dit ervaren.
Wordt er in AV‑projecten nog te vaak gedacht vanuit bestaande bekabeling, in plaats van vanuit de eisen van de toepassing?
En durven we het netwerkontwerp voldoende ter discussie te stellen, ook als het netwerk speciaal voor AV is aangelegd?
Nog meer achtergronden? Lees mijn blog over de AVoIP piramide.
Eric Lindeman, NETGEAR ProAV Staff Systems Engineer Benelux
Voor meer informatie over de NETGEAR AV Switching neem gerust contact op met:
Commercieel: Simon Bol email: simon.bol@netgear.com
Presales: Eric Lindeman email: elindeman@netgear.com
Op het NETGEAR Pro AV Design Team via email: ProAVdesign@netgear.com
of kijk op https://www.netgear.com/nl/business/av/
Een overzicht van onze klassikale AV trainingen in Zoetermeer kan je hier vinden: https://innovatie.netgear.nl/audio-video-over-ip-trainingen/
