Voice chat over lan met geen vertraging

[Joka]

Ik heb een vraag ik wil graag met een kameraad op lan zonder vertraging (voice chat) over lan kunnen praten.
Maar tot nu toe geen enkele programma kunnen die dat bied iemand advies?

mod-edit: Beste Joka, welkom op Tweakers. Bij het stellen van een vraag op GoT verwachten we toch echt meer eigen inzet. Een zo gedetailleerd mogelijk uitleg wat je wilt bewerkstelligen, wat voor hardware je tot je beschikking hebt en wat je allemaal al hebt geprobeerd en gevonden.

[ Voor 45% gewijzigd door Geronimous op 29-11-2017 20:12 ]

[Fietsbel]

Tja, je kan beginnen door even te melden welke programmas je allemaal hebt geprobeerd. Scheelt ons ook weer dezelfde te benoemen...

[swtimmer]

Joka schreef op dinsdag 28 november 2017 @ 23:58:
Ik heb een vraag ik wil graag met een kameraad op lan zonder vertraging (voice chat) over lan kunnen praten.
Maar tot nu toe geen enkele programma kunnen die dat bied iemand advies?

Sneller dan het geluid bedoel je?

[dipje2]

Ik denk dat er misschien wel wat valt in te stellen in Teamspeak dat je minder latency hebt (buffers aanpassen en zo, kan _misschien_ ergens als je je eigen server draait).

Van horen lezen (dus geen eigen ervaring) heeft iemand met dezelfde vraag een antwoord gevonden in 'Mumble'. Eentje stelt een server op op zijn eigen machine (dus speelt voip-host) en de andere connect er naar toe. Mumble claimt erg lage latency en de client + server software is gratis.

Voor de rest wat Fietsbel zei: Als je niet zegt wat je hebt geprobeerd betekent dat je een hoop antwoorden kan krijgen die je misschien al gedaan hebt en dus niet goed genoeg waren voor je.

(Ik vraag mij dus bijvoorbeeld af of je uberhaupt Teamspeak lokaal hebt geprobeerd, of alleen door naar een centrale server te connecten?).

[Joka]

Skype, teamspeak 3 , Discord, Voicemeeter,Vban geprobeerd maar geen succes.
Ik gebruik een headset via minijack met een interne geluidskaart.
kan het zijn dat deze onboardgeluidskaart niet snel genoeg is met de standaard drivers?

[Compizfox]

swtimmer schreef op woensdag 29 november 2017 @ 00:11:
[...]


Sneller dan het geluid bedoel je?

Sneller dan het geluid is technisch prima mogelijk, sneller dan het licht wordt problematisch

---

Joka schreef op woensdag 29 november 2017 @ 00:15:
Skype, teamspeak 3 , Discord, Voicemeeter,Vban geprobeerd maar geen succes.
Ik gebruik een headset via minijack met een interne geluidskaart.
kan het zijn dat deze onboardgeluidskaart niet snel genoeg is met de standaard drivers?

Hoe kritisch is die latency? M.a.w, hoe laag wil je het hebben? 20 ms? 10 ms? 1 ms?

Je hebt denk ik de beste kans op slagen met een lokaal-gehoste TeamSpeak- of Mumble-server. Skype staat niet bepaald bekend om de goede geluidskwaliteit of latency, en Discord moet altijd over het internet.

Met name Mumble adverteert low-latency als een belangrijk selling point, al weet ik niet hoe veel dit in de praktijk verschilt van TeamSpeak.

[ Voor 64% gewijzigd door Compizfox op 29-11-2017 00:19 ]

[DrummerSays]

Je zou zeggen dat het gewoon mogelijk is over over LAN/gigabit (tegenwoordig) een voice-chat te starten zonder/met nagenoeg géén delay... Is mij tot op heden ook nog niet gelukt met de door Joka genoemde programma's.

Is nou serieus met XLR kabels, paar mic's en (een paar) mengtafeltjes de enige solide manier?

[Joka]

we zitten dus eigelijk te zoeken naar een (interne) geluidsmogelijkheid die letterlijk 0ms latency geeft, omdat we in dezelfde ruimte zitten.

[Compizfox]

DrummerSays schreef op woensdag 29 november 2017 @ 00:19:
Je zou zeggen dat het gewoon mogelijk is over over LAN/gigabit (tegenwoordig) een voice-chat te starten zonder/met nagenoeg géén delay... Is mij tot op heden ook nog niet gelukt met de door Joka genoemde programma's.

Is nou serieus met XLR kabels, paar mic's en (een paar) mengtafeltjes de enige solide manier?

Joka schreef op woensdag 29 november 2017 @ 00:20:
we zitten dus eigelijk te zoeken naar een (interne) geluidsmogelijkheid die letterlijk 0ms latency geeft, omdat we in dezelfde ruimte zitten.

Geen delay is onmogelijk vanwege zowel compressie/encoding, en de manier waarop het internet werkt. Audio moet verpakt worden in IP-pakketjes en dat gaat niet met letterlijk 0 delay. Bovendien heb je altijd 'last' van de fundamentele limiet opgelegd door de lichtsnelheid, maar die kun je op deze afstanden verwaarlozen.

Wel zou het mogelijk moeten zijn om de latency te minimaliseren naar enkele milliseconden. Dat zou acceptabel moeten zijn, hoop ik.

[ Voor 23% gewijzigd door Compizfox op 29-11-2017 00:28 ]

[Bobmeister]

Dit kan toch gewoon met een lokale teamspeak server? Sneller ga je het niet krijgen.

[Compizfox]

Awsom schreef op woensdag 29 november 2017 @ 00:22:
Dit kan toch gewoon met een lokale teamspeak server? Sneller ga je het niet krijgen.

Wellicht dat Mumble nog net iets sneller is, maar dat zou je moeten testen.

Hoe dan ook is het inderdaad belangrijk dat je de server lokaal host, dus niet ergens anders op het internet.

[ Voor 17% gewijzigd door Compizfox op 29-11-2017 00:23 ]

[Joka]

hebben ze echt allemaal getest op verschillende manieren.

[DrummerSays]

Hebben jullie ervaring met Voicemeeter + VBAN? Behoorlijk snel, maar blijft een dubbel geluid creeeren als je in dezelfde ruimte zit...

[wagenveld]

Jouw microfoon in zijn line-in en andersom. Absoluut het snelst.

[DrummerSays]

wagenveld schreef op woensdag 29 november 2017 @ 00:24:
Jouw microfoon in zijn line-in en andersom. Absoluut het snelst.

Goeie!

[Compizfox]

Joka schreef op woensdag 29 november 2017 @ 00:23:
hebben ze echt allemaal getest op verschillende manieren.

En, wat kwam daaruit? Hoeveel latency had je met die verschillende programma's, en waarom was dat nog steeds niet acceptabel?

Hoever zit je trouwens van elkaar af? Als dat bijvoorbeeld 5 meter is, zit er al 15 ms delay in het geluid dat door de lucht gaat. Dat zou je met Mumble of Teamspeak wel moeten kunnen inhalen lijkt me.

[Joka]

bijna meer een seconden met max resultaat van 0.5 delay.
we zitten ook hooguit een meter van elkaar xD

[Compizfox]

Joka schreef op woensdag 29 november 2017 @ 00:29:
bijna meer een seconden met max resultaat van 0.5 delay.
we zitten ook hooguit een meter van elkaar xD

Meer dan een seconde? Dat zou veel beter moeten kunnen.

Op deze blog van Mumble hebben ze het over records van 40 tot 50 ms. (toegegeven, dat is iets hoger dan ik voor ogen had, maar nog steeds heel weinig)

[ Voor 28% gewijzigd door Compizfox op 29-11-2017 00:35 ]

[Joka]

ik heb alleen een noice canceling headset van sennheiser pc350 dus dan hoor je het behoorlijk brak.
over het (gamegeluid).

[ Voor 10% gewijzigd door Joka op 29-11-2017 00:34 ]

[True]

Ik maak nergens op dat je ook daadwerkelijk zelf de server host in plaats van dat je een server gebruikt op het internet. Sowieso gaan Skype of Discord vertraagd zijn, dat werkt nu eenmaal zo.

Heb jij al überhaupt geprobeerd om een eigen server te hosten? En zitten jullie bedraad verbonden aan dezelfde router / switch of per WiFi?

Compizfox schreef op woensdag 29 november 2017 @ 00:30:
[...]

Meer dan een seconde? Dat zou veel beter moeten kunnen.

Op deze blog van Mumble hebben ze het over records van 40 tot 50 ms. (toegegeven, dat is iets hoger dan ik voor ogen had, maar nog steeds heel weinig)

Op mijn eigen Murmur (Mumble server) trek ik
[00:37:27] Server maximum network bandwidth is only 96 kbit/s. Audio quality auto-adjusted to 67 kbit/s (10 ms)
Dus dat is 10 ms naar de server, ruim gedacht 20 ms totaal. Dit staat op een VPS bij een super goedkope VPS provider in NL. Pingen naar mijn Murmur server geeft mij 4 ms. Dan vind ik 10 ms behoorlijk redelijk te noemen voor VoIP.

[ Voor 66% gewijzigd door True op 29-11-2017 00:39 ]

[Petervanakelyen]

DrummerSays schreef op woensdag 29 november 2017 @ 00:19:
Is nou serieus met XLR kabels, paar mic's en (een paar) mengtafeltjes de enige solide manier?

Leuk dat je dit aanhaalt. Alle audioprocessing (leveling, compressie, limiting) in radiostudio's is tegenwoordig digitaal, met één uitzondering: de audiofeed die naar de hoofdtelefoon van de DJ gaat. Die is in veel gevallen nog analoog. De reden daarvoor is latency: als je jezelf met een paar miliseconden vertraging hoort terwijl je aan het praten bent, wordt je helemaal knetter. Analoge apparaten hebben quasi geen (merkbare) vertraging, waar dat (zoals Compizfox reeds aanhaalde) bij digitale apparaten bijna onmogelijk is door de AD/DA conversie en sample rate.

Kortom: neem lekker een paar XLR kabels, microfoons en analoog mengtafeltje, beter gaat het niet worden

[Joka]

zelfs met de localhost met teamspeak zit er enorm vertraging in.

[dipje2]

letterlijk 0 ga je niet krijgen natuurlijk.. een goede (home-studio) achtige audio-interface geeft tussen de 3 a 10ms aan latency. Maar dat is de latency die je niet zo snel zult merken voor Voip achtige dingen.
Mumble naar een server op het LAN gooit daar 10ms a 30ms bij, beter krijg je niet.

Als je dichtbij genoeg zit om je te storen aan het geluid wat je 'in het echt 'hoort en door de headset heen, zit je ook dichtbij genoeg om een paar meter microfoon kabel aan te sluiten op een simpel mengtafeltje met 2 faders. Dit komt op hetzelfde neer als wat hier boven al ergens werd gezegd: mic in ingang van de andere prikken en _geen_ voip gebruiken, maar op je audiokaart gewoon directe monitoring aanzetten. Dus jouw mic in de andere mic-in, en de andere mic in jouw mic-in.

[Joka]

Dan gaan we ons maar even focussen op analoge oplossing dmv mengtafeltje, mic's etc.

Dank voor het meedenken

[H3llrais3r]

als je lag hebt met teamspeak moet je jezelf af gaan vragen of je geen netwerk/hardware problemen hebt...
vorig jaar teamspeak servertje gedraait met 8 man in locale Lan en allen in 1 woonkamer (1 grote duitse klap tafel)

host -> Laptop Dell latitude e5540 (en daar werd dan ook nog op gespeeld)
netwerk -> bedraad en sommige wireless(laptops)

[FrankHe]

De flow is als volgt:
microfoon -> soundcard hardware -> soundcard driver -> windows -> VOIP software ->
lokaal netwerk -> router -> ISP -> internet ->
internet -> ISP -> router -> lokaal netwerk -> VOIP software -> windows -> soundcard driver -> soundcard hardware -> hoofdtelefoon.

Eerste verdacht is de soundcard driver software aan beide kanten. In het meest extreme geval wanneer je een product van bijvoorbeeld RME-Audio of vergelijkbaar merk gebruikt kun je de latency terugschroeven tot pakweg 3 ms. De meeste andere soundcard hardware en soundcard driver combinaties zullen doorgaans niet veel verder komen dan tussen de 25 ms en 250 ms. Dat is inderdaad een verschil van een factor 10 en factor 100.

[RGAT]

Vraag me dan toch af hoe laag die latency moet zijn, Teamspeak hier is altijd <1ms (lokaal gehost) en gebruikers op een andere provider die over glasvezel gaan 5-6ms, Ziggo koper 8ms.
Daar kan het probleem niet liggen als je dat gewoon goed instelt

[B00st3r]

Met geen = zonder

[corporalnl]

Wat dacht je van geen voice gebruiken? En als je dit toch wel nodig hebt ivm er meer mensen zijn. Dan kan je toch zijn stem geluid uitzetten? En hij die van jou? Of is je headset een bouwkoptelefoon dat je niks hoort van buiten?

[CH4OS]

Joka schreef op woensdag 29 november 2017 @ 00:20:
we zitten dus eigelijk te zoeken naar een (interne) geluidsmogelijkheid die letterlijk 0ms latency geeft, omdat we in dezelfde ruimte zitten.

Als jullie met zijn allen in 1 ruimte zitten is het natuurlijk simpel. Koptelefoon af, speakers zachtjes aan. Opgelost.

Zitten er toch spelers bij die elders zitten, dan zet je een eigen TeamSpeak of Murmur (Mumble) op, maar dan ga je het verschil nauwelijks merken, ook al is de delay een 50ms. Vanaf een delay van 100ms ga je (in geval van VoIP zeker) het pas merken, maar dat kan je dan eventueel oplossen door QoS goed in te stellen op het netwerk.

[ Voor 32% gewijzigd door CH4OS op 29-11-2017 11:47 ]

[Compizfox]

RGAT schreef op woensdag 29 november 2017 @ 10:38:
Vraag me dan toch af hoe laag die latency moet zijn, Teamspeak hier is altijd <1ms (lokaal gehost) en gebruikers op een andere provider die over glasvezel gaan 5-6ms, Ziggo koper 8ms.
Daar kan het probleem niet liggen als je dat gewoon goed instelt

Maar dat is dan de ping, niet de totale latency van het geluid, lijkt me.

[Tsurany]

corporalnl schreef op woensdag 29 november 2017 @ 11:36:
Wat dacht je van geen voice gebruiken? En als je dit toch wel nodig hebt ivm er meer mensen zijn. Dan kan je toch zijn stem geluid uitzetten? En hij die van jou? Of is je headset een bouwkoptelefoon dat je niks hoort van buiten?

Dit lijkt mij de beste oplossing inderdaad, waarom wil je elkaar horen via de headset?

[Bobmeister]

corporalnl schreef op woensdag 29 november 2017 @ 11:36:
Wat dacht je van geen voice gebruiken? En als je dit toch wel nodig hebt ivm er meer mensen zijn. Dan kan je toch zijn stem geluid uitzetten? En hij die van jou? Of is je headset een bouwkoptelefoon dat je niks hoort van buiten?

Ja, PC350

Tsurany schreef op woensdag 29 november 2017 @ 12:00:
[...]

Dit lijkt mij de beste oplossing inderdaad, waarom wil je elkaar horen via de headset?

Omdat je het geluid ingame ook nog wilt horen en dat gaat niet als je één schelp van je oor hebt (want met zo'n 350 op mag je flink schreeuwen).

[ Voor 7% gewijzigd door Bobmeister op 29-11-2017 12:39 ]

[Tsurany]

Wat maakt de delay dan uit als je elkaar toch niet hoort?

[FrankHe]

RGAT schreef op woensdag 29 november 2017 @ 10:38:
Vraag me dan toch af hoe laag die latency moet zijn, Teamspeak hier is altijd <1ms (lokaal gehost) en gebruikers op een andere provider die over glasvezel gaan 5-6ms, Ziggo koper 8ms.
Daar kan het probleem niet liggen als je dat gewoon goed instelt

Dat is de roundtrip (ping) tijd tussen de computers op het netwerk. De totale latency tussen microfoon van persoon A en de hoofdtelefoon van persoon B kan dan nog steeds gemakkelijk een halve seconde zijn.

[ Voor 0% gewijzigd door FrankHe op 29-11-2017 15:05 . Reden: persoon 'B' ]

[Slavy]

Joka schreef op woensdag 29 november 2017 @ 00:45:
zelfs met de localhost met teamspeak zit er enorm vertraging in.

Ook als iedereen naar intern IP verbind? Als je namelijk lokaal host en de gebruikers naar het lokale IP laat verbinden zou je geen vertraging moeten hebben, ik doe dit namelijk zelf soms ook.

[RGAT]

FrankHe schreef op woensdag 29 november 2017 @ 15:03:
[...]

Dat is de roundtrip (ping) tijd tussen de computers op het netwerk. De totale latency tussen microfoon van persoon A en de hoofdtelefoon van persoon B kan dan nog steeds gemakkelijk een halve seconde zijn.

Dat kan best, maar op die punten heeft de software geen invloed natuurlijk, zelfs de goedkope Realtek audiochips doen dit snel genoeg dat je het nauwelijks merkt.
Enige keer dat het merkbaar was gebeurde toen we op twee servers zaten met verschillende groepen, audio werd via de ene server naar een bot op de tweede server gestuurd en andersom om echo te voorkomen, maar dat was van NL naar US en terug, te verwachten

[BernardV]

Je zou deze drivers ook kunnen proberen, zou wel eens kunnen helpen: http://www.asio4all.de/

Sinds XP is de audio in windows aardig aangepast en er zijn vele klachten over delay in opnames.

[FrankHe]

RGAT schreef op woensdag 29 november 2017 @ 15:25:
Dat kan best, maar op die punten heeft de software geen invloed natuurlijk, zelfs de goedkope Realtek audiochips doen dit snel genoeg dat je het nauwelijks merkt.
Enige keer dat het merkbaar was gebeurde toen we op twee servers zaten met verschillende groepen, audio werd via de ene server naar een bot op de tweede server gestuurd en andersom om echo te voorkomen, maar dat was van NL naar US en terug, te verwachten

Ik ga ze even VET drukken:

FrankHe schreef op woensdag 29 november 2017 @ 10:33:
De flow is als volgt:
microfoon -> soundcard hardware -> soundcard driver -> windows -> VOIP software ->
lokaal netwerk -> router -> ISP -> internet ->
internet -> ISP -> router -> lokaal netwerk -> VOIP software -> windows -> soundcard driver -> soundcard hardware -> hoofdtelefoon.

Als je in de drivers van de soundcard niet de mogelijkheid hebt om de buffergrootte aan te passen dan loop je op dat punt geheid de meeste vertraging op. Een ander punt waarop het mis kan gaan is de buffergrootte die de VOIP software hanteert. Alle overige componenten dragen ook wel bij aan latency maar hun invloed is naar verhouding redelijk beperkt.

[RGAT]

FrankHe schreef op woensdag 29 november 2017 @ 15:34:
[...]


Ik ga ze even VET drukken:

[...]


Als je in de drivers van de soundcard niet de mogelijkheid hebt om de buffergrootte aan te passen dan loop je op dat punt geheid de meeste vertraging op. Een ander punt waarop het mis kan gaan is de buffergrootte die de VOIP software hanteert. Alle overige componenten dragen ook wel bij aan latency maar hun invloed is naar verhouding redelijk beperkt.

Zal ik mijn zin ook vet gedrukt doen
Waar in jouw Teamspeak server stel jij client sounddriver settings in? Want daar had ik het over dat de Teamspeak software daar niks aan kan doen...

[FrankHe]

RGAT schreef op woensdag 29 november 2017 @ 16:21:
[...]

Zal ik mijn zin ook vet gedrukt doen
Waar in jouw Teamspeak server stel jij client sounddriver settings in? Want daar had ik het over dat de Teamspeak software daar niks aan kan doen...

Vet man Het is ook geen instelling van teamspeak of welk programma je ook gebruikt. Het is een instelling van de driversoftware die ervoor zorgt dat de soundcard hardware met windows praat. Jouw VIOP toepassing praat vervolgens weer met windows.

Ik gebruik geen teamspeak maar weet wel het nodige van soundcards in het algemeen met toepassing in professionele muziekproductie in het bijzonder. Op die driversoftware loop je doorgaans de meeste latency oploopt. Iedereen heeft het hier telkens maar network latency. Mijn punt is dat dit maar een klein deel is van het verhaal en er nog meer factoren zijn waarmee je rekening dient te houden.

[RGAT]

FrankHe schreef op donderdag 30 november 2017 @ 08:57:
[...]

Vet man Het is ook geen instelling van teamspeak of welk programma je ook gebruikt. Het is een instelling van de driversoftware die ervoor zorgt dat de soundcard hardware met windows praat. Jouw VIOP toepassing praat vervolgens weer met windows.

Ik gebruik geen teamspeak maar weet wel het nodige van soundcards in het algemeen met toepassing in professionele muziekproductie in het bijzonder. Op die driversoftware loop je doorgaans de meeste latency oploopt. Iedereen heeft het hier telkens maar network latency. Mijn punt is dat dit maar een klein deel is van het verhaal en er nog meer factoren zijn waarmee je rekening dient te houden.

Is dan dus ook wat ik zei... Dat je wel heel raar bezig moet zijn wil je in Teamspeak die vertraging oplopen...
Maar je hebt het mooi herhaald

[FrankHe]

RGAT schreef op donderdag 30 november 2017 @ 09:15:
Is dan dus ook wat ik zei... Dat je wel heel raar bezig moet zijn wil je in Teamspeak die vertraging oplopen...
Maar je hebt het mooi herhaald

De meeste mensen zullen het niet merken dat hun Realtek soundchip en driversoftware voor latency zorgt. Of het nu 25 ms is of 250 ms. Bij die laatste waarde ga je het wel een beetje merken. Bij VOIP toepassingen kun je doorgaans wel wegkomen met de ingebouwde soundcard. Voor muziekproductie is eigenlijk 10 ms al bijna te veel. Dat is dan ook een van de redenen dat er extreem dure soudcards worden aangeschaft voor het produceren van muziek. Als je met VOIP ook echt hele lage latency wilt dan is het mogelijk dat de (in de computer) ingebouwde soundchip en de bijgeleverde driversoftware niet volstaat voor de performance die je zoekt.

[RGAT]

FrankHe schreef op donderdag 30 november 2017 @ 12:12:
[...]

De meeste mensen zullen het niet merken dat hun Realtek soundchip en driversoftware voor latency zorgt. Of het nu 25 ms is of 250 ms. Bij die laatste waarde ga je het wel een beetje merken. Bij VOIP toepassingen kun je doorgaans wel wegkomen met de ingebouwde soundcard. Voor muziekproductie is eigenlijk 10 ms al bijna te veel. Dat is dan ook een van de redenen dat er extreem dure soudcards worden aangeschaft voor het produceren van muziek. Als je met VOIP ook echt hele lage latency wilt dan is het mogelijk dat de (in de computer) ingebouwde soundchip en de bijgeleverde driversoftware niet volstaat voor de performance die je zoekt.

Mooi

[elhopo]

Petervanakelyen schreef op woensdag 29 november 2017 @ 00:37:
[...]


Leuk dat je dit aanhaalt. Alle audioprocessing (leveling, compressie, limiting) in radiostudio's is tegenwoordig digitaal, met één uitzondering: de audiofeed die naar de hoofdtelefoon van de DJ gaat. Die is in veel gevallen nog analoog. De reden daarvoor is latency: als je jezelf met een paar miliseconden vertraging hoort terwijl je aan het praten bent, wordt je helemaal knetter. Analoge apparaten hebben quasi geen (merkbare) vertraging, waar dat (zoals Compizfox reeds aanhaalde) bij digitale apparaten bijna onmogelijk is door de AD/DA conversie en sample rate.

Kortom: neem lekker een paar XLR kabels, microfoons en analoog mengtafeltje, beter gaat het niet worden

Nee hoor, de audio feedback naar de DJ is ook digitaal. Bij 538 en NOS enzo staan mixers van het merk DHD. Deze werken allemaal met audio units die met UTP kabeltjes (dus digitaal) op een mainprocessor aangesloten zitten. Bijvoorbeeld een unit waar je microfoons en koptelefoons op kan aansluiten. Vanaf deze mainprocessor zit de mixer weer met UTP aangesloten, en daar kan je de DJ koptelefoon op aansluiten. Alles dus digitaal. Ook binnen een enkele unit.

Overigens wordt het pas een probleem (en niet werkbaar) als de vertraging te groot is, een paar ms merk je niets van. Deze modules zijn over gigabit verbonden.

[Petervanakelyen]

Met AES67 (en eigen AoIP implementaties zoals die van DHD) kan het ook digitaal inderdaad, maar die had ik voor het gemak weggelaten, ook omdat ze wellicht niet in het budget van TS passen

[FrankHe]

In die professionele apparatuur drukken ze de latency ook niet uit in ms maar in samples. Bijvoorbeeld Normale waardes liggen ergens rond de 20 en 200 samples. Bij een sample frequentie van 44.100 Hz is dat respectievelijk 0.45 ms en 4.5 ms. Heel erg laag dus. De gemiddelde consumenten soundchip komt waarschijnlijk niet heel veel verder dan 45 ms voor een roundtrip.