Audio Codec

Sprache ist eigentlich ein analoges Signal. Auch Bilder haben eigentlich "unendlich" viele Farben. Aber der Mensch ist zum einen sehr tolerant bzw. "unempfindlich" was Töne und Bilder betrifft und zum anderen denken Computer nun mal binär. Es gibt auch analoge Computer aber das ist ein anderes Thema. Fakt ist aber, dass die meisten Menschen höhere Töne nicht mehr hören, wenn Sie von lauteren und tieferen Tönen überlagert sind. Auch bei Bildern sind durchaus kompromissbereit.

Die Auswirkungen können wir täglich erleben. Das Alpen-Panorma ist schon beeindruckender, wenn man auf der Aussichtsplattform steht. Trotzdem werden viele Bilder mit x Megapixel "geschossen" und dann auf dem heimischen Monitor oder "Pictureframe" mit 800x600 Pixel angeschaut. Und bei Musik geben sich die meisten Menschen mit MP3-Dateien und 128kbit Auflösung zufrieden, weil sie mehr doch nicht unterscheiden können. Und beim telefonieren über Mobilfunk (GSM) sind es sogar nur 13,7kbit. Und damit sind wir in der Welt der Codec.

Abtastung und Kompression

Ein Codec ist letztlich nichts anderes als eine Beschreibung, wie Informationen zu erfassen und gegebenenfalls zu komprimieren sind und später wieder zurückverwandelt werden können. Diese "Anleitung" wird von Programmierern in entsprechenden Code umgesetzt, der dann aus Signalen entsprechende Bits macht. Im Laufe der Entwicklung wurden verschiedene Codecs entworfen, von denen einige auch durch Patente geschützt sind, andere nicht. Auch die Qualität und die Anforderungen unterscheiden sich erheblich.

  • Abtastung
    Analoge Signale werden wiederholt digitalisiert und damit in Bits und Bytes umgewandelt. Bekannt ist sicher das ISDN-Format, bei dem das Tonsignal 8000 Mal pro Sekunde mit 8 Bit digitalisiert wird, d.h. aus den analogen Spannungen wird eine Zahl von -128 bis 127. (8 Bit eben). Das Ergebnis ist dann ein kontinuierlicher Datenstrom von 64kBit. Genau die ISDN-Übertragungsrate. Komprimiert wird da nicht. CPU-Leistung war damals noch begrenzt. Wer etwas Nachrichtentechnik kennt, weiß aber nun, dass man mit 8000 Messpunkten nur eine maximale Frequenz von 4kHz ermessen kann. Rechnerisch hören die meisten Menschen diese höheren Frequenzen aber nicht:

    Quelle: http://de.wikipedia.org/wiki/H%C3%B6rfl%C3%A4che

    Hohe Töne kommen also nicht durch, aber sind auch nicht wichtig.. Beschränkt man aber die Abtastung weiter, dann klingt die Stimme nicht nur flach, sondern bestimmte Laute lassen sich nicht mehr unterscheiden, z.B. "f" und "s". Diese unterscheiden sich fast nur in hohen Tönen. Entsprechende "Wideband"-Codec tasten z.B. 16000/Sek ab. Die zusätzliche Datenrate muss man natürlich wieder durch Kompression einstampfen. Anders als bei einer Datenkompression ist unser Ohr aber noch tolerant, so das sogar "Verluste" in einem bestimmten Rahmen toleriert werden. Ein mit 64kbit digitalisierter MP3-Song hört sich immer noch besser an, als über das Telefon abgespielt.
    Bei Bildern ist quasi die "Bildwiederholrate", fps (Frames per Second) ein Faktor, der bestimmt, wie oft ein neues Bild erfasst wird. Damit die Datenmenge nicht immens steigt, kann ein Codec hier aber z.B. nur die Änderungen zum vorherigen Bild übertragen.
  • Kompression
    Sie können alle die Kompression durch effektiver Speicherung. Bei Daten gibt es z.B. das ZIP-Format, bei Bildern z.B. PNG oder GIF, die verlustfrei arbeiten. Durch das Einpacken, Übertragen und spätere Entpacken gehen keine Daten verloren. Das ist bei Tönen und erst recht bei Bildern nicht erforderlich. die nagelneue 8 Megapixel-Kamera speichert ihre Bilder per JPG Kompression mit sehr viel weniger Platzbedarf ab. Das kann sie nur, weil Sie Bildinformationen zusammenfasst. Ein Mensch kann geringe Farb- oder Helligkeitsunterschiede nicht erkennen, so dass man keine 100 Nuancen von Blau übertragen muss. Dafür sind die Kanten wichtiger. Trotzdem können beim bewegten Bild viele Informationen weg gerechnet werden. Wenn man dann noch nur "Änderungen " überträgt, dann wir das Volumen weiter reduziert. Auf die einzelnen Details will und kann ich hier nicht eingehen, aber es gibt auch hier für jeden Anwendungsfall den passenden Codec.
  • Fehlerkorrektur
    Nun können bei der Übertragung über das Netzwerk auch mal Pakete verloren gehen. Eine abgesicherte Verbindung mit "erneutem Zusenden" ist bei Computerdaten wichtig. Hier darf kein Bit fehlen. Daher nutzen viele Protokolle (SMTP, HTTP, FTP, SMB, RDP etc.) alle TCP als unterbau. Wenn aber von einer Audioübertragung mal 20millisekunden fehlen, dann werden Sie das in der Regel gar nicht merken. Ein einzelnes Paket muss man also nicht wieder senden. Fehlen aber zu viele, dann gibt es doch unschöne Aussetzer oder metallisch klingende Seitentöne. Bestimmte Codec können das erkennen und senden dann zusätzliche Pakete, so dass beim Ausfall eines Pakets der Inhalt rekonstruiert werden kann. Stellen Sie sich einfach vor, es gäbe sowas wie ein RAID, nur dass hier nicht die Daten auf N+1 Disks verteilt werden, sondern eben das Startbild auf z.B. in 10 Bilder passt und ein 11tes Prüfsummenpaket mitkommt. Bei Bildern ist dies vor allem für das I-Frame wichtig, welches üblicherweise eine "Group of Pictures" (GOP) einleitet und ohne das die Folgepaket wertlos sind. Das ist der Grund, warum ein Film auch mal einige Sekunden "hängen" kann oder sie nicht sekundengenau vor und zurückspulen können.

Sie sehen also, das schon ohne eine detaillierte Auseinandersetzung mit den mathematischen Besonderheiten die Thematik sehr umfangreich werden kann.

Beispiel G.711

Die Thematik der Abtastung lässt sich an einem nicht komprimierenden Verfahren wie dem G.711-Codec sehr einfach aufzeigen. Bei einer Abtastrate von 8000 Messpunkten pro Sekunde mit einer Auflösung von 8 Bit ( also -127 bis 128) kommen damit 64kbit (8000x8) zusammen.

Damit die Zeitverzögerung der Sprache nicht zu groß wird, werden immer 20 Millisekunden in einem Block versendet. Aus der Sekunde werden als 50 Pakete mit den Daten von 20ms.

Zieht man so einen Abschnitt noch etwas größer, dann erkennt man sogar die einzelnen digitalisierten diskreten Punkte

 

Bei 8000 Messpunkten /50 Pakete sind dies also 160 einzelne Werte, oder eben 160 Byte, die im Ethernet Paket übertragen werden. Schaut man sich ein solches Paket dann aber mal im Ethernet an (Hier WiFi) dann sieht man den Overhead

Es werden hier 171 Bytes "Nutzlast" übertragen. Darauf kommt aber noch der UDP-Header (+20 Byte), der IP-Anteil (+20 Byte) und dann noch der Ethernet (bzw. hier WiFi), so dass am Ende 275 Byte übertragen werden. Der Overhead würde prozentual weniger, wenn man mehr Daten pro Paket versenden würde. Wer aber z.B. 40ms einpackt verzögert auch die Übertragung noch mehr. Zudem würde dann ein Paketverlust gleich einen deutlicher hörbaren "Aussetzer" verursachen. Einige Codecs sind daher flexibel und müssen die Laufzeiten, Verluste etc. Und passen dynamisch die Abtastintervalle an.

Audio-Codecs im Detail

In Verbindung mit Lync, OCS, VoIP und Video kommen einige Codecs zum Einsatz. Lync wechselt sogar Codecs im laufenden Gespräch, z.B. wenn die Bandbreite zu knapp wird, die Fehlerrate ansteigt. Auch ist es ein unterschied, ob ein Lync Client mit einem anderen Lync-Client verbunden ist, oder ob mittels "Media Bypass" der Client direkt mit dem Gateway spricht. Bei Konferenzen hingegen muss man die Arbeit der zentralen Mixerstelle (MCU) optimieren und verzichtet vielleicht auf den "besten" Codec zugunsten eines Codecs mit weniger Rechenbedarf.

Da viele Codes auch "Stille" erkennen können und dann reduziert senden (und der Empfänger ein "Comfort Noise-Signal" wiedergibt, ist die Bandbreite als "Obere Grenze ohne Fehlerkorrektur" angegeben. Zudem habe ich (außer bei GSM) die Bandbreite auf Ethernet umgesetzt. Zu den 64kbit G.711 kommt ja noch der Ethernet Overhead dazu.

Codec Bandbreite (Max ohne FEC) MOS Einsatzzweck

GSM verschiedene

6,5-13kbps

 

Im GSM-Netz werden binäre Daten übertragen und das ist "teuer". abgestimmt auf die Slots (TDM)-Verfahren) und die Leistung der Geräte kommen verschiedene Codecs zum Einsatz, die meist nur 3.1 KHz übertragen können und natürlich stark komprimieren.

G.711a/PCMA
G.711u/PCMU

97 kbs

4,4
4,2

Dieser Codec wird im ISDN-Netz eingesetzt und tastet 64kbit ab. Er wird auch als PCMA aLaw (Europa) und PCMU uLaw (USA) bezeichnet. Der Einsatz bei VoIP ist besonders einfach, da ein Gateway die Daten dann nicht umkodieren muss. Die unterschiedliche Qualität kommt daher, dass uLaw mit 56kbit und aLaw mit 64kbit abgetastet wird
http://en.wikipedia.org/wiki/G.711

G.722

101 kbs

 

Dieser Codec ist ein "Wideband/Stereo" Codec, d.h. tastet höher (16khz) und mit 14 Bit ab und kommt z.B. in Konferenzen oft zum Einsatz. Auch Lync nutzt den Codec für Audio-Konferenzen.

Achtung: G722.1 ist eher mit Siren vergleichbar und nicht mit G.722

G.722/2

161 kbs

 

Stereo-Version des G.722 und wird u.a. vom Lync Room System genutzt

RTAudio8

45kbs

 

Dies ist der von Microsoft native genutzte Codec, um Audio zwischen PCs zu übertragen. Dank Kompression, die natürlich auch aufgrund des Computers einfacher ist, kommt der Codec mit relativ wenige Bandbreite aus. Bedenken Sie, dass der Ethernet overhead für alle gleich ist.

RTAudio16

62kbs

Dies ist die "Wideband" Variante, die höher auslöst

Silk

41-64 kbit/s

 

Codec von Skype (Consumer), der aber mittlerweile auch von Skype für Business und Lync 2013 genutzt wird.

Opus

6 bis 40 kbit/s 

 

Dynamischer Codec für WebRTC der von SILK abgeleitet wurde

Siren

53 kbs

 

Ursprünglich von Picturetel (Heute Polycom) entwickelter Codec, der von OCS 2007R2 noch für Konferenzen genutzt wird
http://en.wikipedia.org/wiki/Siren_Codec

T.38

 

 

Dieser Codes ist für FAX optimiert. Beim Übergang aus dem PSTN-Netz sollte das Gateway die "Faxtöne" quasi schon digitalisieren, so dass der Codec schon das binäre Fax überträgt und keine digitalisierten Töne. Damit muss man zum einen nicht 64kbit abtasten, da die meisten Faxgeräte gerate mal 14000 Baud nutzen und T.38 enthält zudem die Funktion, verlorene Pakete erneut zu übertragen (Feherlsicherung). T.38 ist daher sehr ratsam für Fax. Leider erfordert dies leistungsfähigere Gateways und eine Unterstützung bei Endpunkte.
http://en.wikipedia.org/wiki/T.38

G.723.1

 

 

Lizenzpflichtiger Codec mit sehr hoher Kompression und schlechter Audioqualität. Kommt aber oft in VoIP-Umgebungen vor und wird von Exchange UM unterstützt.
http://en.wikipedia.org/wiki/G.723.1

G.726-40
G.726-32
G.726-24
G.726-16

 

4,2
3,9
3,3
2,5

Die Angabe 40,32,24 und 16 steht für die Absatzrate
http://en.wikipedia.org/wiki/G.726

G.729

 

 

 

AMR
WB
ILBC

 

 

Codecs werden in Mobilfunknetzten genutzt und kommen ggfls. bei einem SIP-Trunk seitens des Providers mit an. Lync kann dieses Codecs nicht. Eventuell könnte eine SBC dieses transcodieren. Ansonsten setzte der Carrier die Sprache z.B. auf G.711 um.

Es gibt noch eine ganze Menge weiterer Codecs, aber diese sind üblich im Bereich VoIP.

Bei Audio-Konferenzen ist es üblich, die verschiedenen einkommenden Tonsignale zu "mixen", d.h. hier ist es dann wichtig, dass der Codec die MCU nicht überfordert. Sie muss ja zumindest die wenige Audioströme decodieren und zusammenfügen, die dann wieder an alle Teilnehmer verteilt werden. Hoffen wir mal, dass die meisten Teilnehmer "schweigen und auch keine Hintergrundgeräusch die "Erkennung der Stille" verhindern.

MOS-Wert (Mean Opinion Score)

MOS ist die Abkürzung für "Mean Opinion Score". Die Qualität einer Sprachverbindung wird in der Telekommunikation anhand des MOS-Werts angegeben. Die Scala von MOS reicht dabei von 1 (schlecht) bis 5 (sehr gut). Der MOS-Wert beruht auf einer Testreihe mit einer Gruppe von Versuchspersonen und stellt daher einen subjektiven Wert zur Beurteilung der Qualität der Sprachübertragung dar. Im ISDN wird ein MOS-Wert von knapp über 4 erreicht. Die Qualität hängt von der Übertragungsleitung aber auch vom verwendeten Codec ab.

Codec im SDP

VoIP ist ja immer eine 1:1 Kommunikation zwischen zwei Endpunkten. Auch eine Konferenz aus drei oder mehr Teilnehmern ist immer eine P2P-Verbindung des Teilnehmers zur Konferenzbridge (MCU). Im Rahmen des SIP-INVITE und der 200OK Bestätigung senden die Clients im SDP - Session Description Protocol die Liste der unterstützten Codec mit. Hier ein Beispiel

Content-Type: application/sdp
Content-Length: 1136

v=0
o=- 0 2 IN IP4 192.168.102.35
s=session
c=IN IP4 192.168.102.35
b=CT:99980
t=0 0
a=x-devicecaps:audio:send,recv;video:send,recv
m=audio 17188 RTP/SAVP 114 104 9 112 111 0 8 116 115 103 97 13 118 101
a=x-ssrc-range:972034414-972034414
a=rtcp-fb:* x-message app send:dsh recv:dsh
a=rtcp-rsize
a=label:main-audio
a=x-source:main-audio
a=ice-ufrag:VA63
a=ice-pwd:TEC6eCd1XfjVB8IKTFsoiHUC
a=candidate:1 1 UDP 2130706431 192.168.102.35 17188 typ host 
a=candidate:1 2 UDP 2130705918 192.168.102.35 17189 typ host 
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:86qfwMq4QIliQQPgCzzFVtaW2dltUxKOE5vr7WH7|2^31|1:1
a=remote-candidates:1 192.168.102.62 20628 2 192.168.102.62 20629
a=maxptime:200
a=rtpmap:114 x-msrta/16000
a=fmtp:114 bitrate=29000
a=rtpmap:104 SILK/16000
a=fmtp:104 useinbandfec=1; usedtx=0
a=rtpmap:9 G722/8000
a=rtpmap:112 G7221/16000
a=fmtp:112 bitrate=24000
a=rtpmap:111 SIREN/16000
a=fmtp:111 bitrate=16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:116 AAL2-G726-32/8000
a=rtpmap:115 x-msrta/8000
a=fmtp:115 bitrate=11800
a=rtpmap:103 SILK/8000 
a=fmtp:103 useinbandfec=1; usedtx=0 
a=rtpmap:97 RED/8000
a=rtpmap:13 CN/8000
a=rtpmap:118 CN/16000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:

Jeder Codec bekommt eine Nummer auf die später referenziert wird. Wer genau hingeschaut hat, kann hier auch den Codec "SILK" erkennen, den Skype nutzt.

Welche Codecs letztlich zum Einsatz kommen, handeln die beiden Endpunkte zum einen beim SIP-INVITE/OK auf und aus der Gruppe der übereinstimmenden Codecs können Sie dann während der Kommunikation im RTP-Datenfluss wechseln. Dort ist die "Nummer" auch enthalten.

Hier gut zu sehen, dass 192.168.102.35 mit dem Codes 114 (msRTAudio) sendet während 192.168.102.62 gerade "Stille" sendet (Codec CN = Comfort Noise = 118)

TCP oder UDP

Da Audio und Video eher "flüchtige" Informationen sind, ist ein Verlust einiger Pakete problemlos zu tolerieren. Daher ist auch keine Transportsicherung über TCP erforderlich. Welches Protokoll genutzt wird, ist aber bezüglich des Codec irrelevant. Diese sind ja nur die Nutzlast und können sowohl über UDP als auch über TCP übertragen werden.

UDP ist aufgrund seiner Funktion natürlich präferiert und es sind keine TCP-Quittungen und erst recht keine "Retransmissions" erforderlich. Was bringt ihnen ein erneut übertragenes Paket, welches Töne enthält, die in der Vergangenheit liege. Trotzdem kann es vorkommen, dass die Daten über TCP übertragen werden, z.B. wenn UDP durch die Firewall geblockt wird.

Auch wer mit VPNs arbeitet, wird gar nicht merken, dass die UDP-Daten wieder in TCP-Pakete eingepackt werden. Dabei werden Sie im schlimmsten Fall noch fragmentiert (MTU-Size). Es ist daher immer zu überlegen, wie z.B. die bei OCS/Lync eh verschlüsselten Audio/Video-Daten am VPN vorbei kommen können, z.B. indem mal die Edge-Server aus dem VPN ausschließt. Das betrifft Routing, Firewall-Regeln aber auch die DNS-Auflösung.

Latenzzeit

Die Verzögerung von Audiosignalen ist ein weiteres Thema, welche direkt mir der "gehörten Qualität" verbunden ist und oft allein auf den Codec geschoben wird. Natürlich ist auch ein Codec und die Paketgröße für eine gewisse Signalverzögerung verantwortlich. Schließlich muss er die Audiodaten ja erst einsammeln, abtasten und als Paket formatieren. Kommen dann noch "Fehlerkorrektur" und Jitter-Buffer dazu, dann ist auch auf der Empfangsseite eine Verzögerung zu erkennen. Aber das sind bei weitem nicht die einzigen Verzögerungen. Schauen wir uns exemplarisch mal die Schritte an:

Position Verzögerung Total

Die Töne verlassen den Mund des Sprechers

0ms

0ms

Übertragung bis zum Mikrofon. (Schallwellen ist kein Licht und viel schneller als 300m/s breiten sich Druckwellen in unserem Lebensraum nicht aus. Bei einem Meter Abstand wären da schon die ersten 3ms, die aber niemand wirklich wahrnimmt. Sie würden auch nur eingehen, wenn Sie quasi "Freisprechen" mit einem weiter entfernten Mikrofon nutzen würden.

0ms

0ms

A/D-Wandlung. Das Mikrofon nimmt die analogen Druckschwankungen auf und setzt diese in elektrische Signale um, was noch relativ schnell geht. Die Umsetzung in ein USB-Bus-Paket und Übertragung zum PC kann aber je nach Soundgerät schon deutliche Verzögerungen haben. Insbesondere wenn das Mikrofon selbst noch "Soundverbesserungen" wie Echounterdrückung und Popp/Knack-Schutz-Filter enthält. "UC-Headsets" achten z.B. darauf, dass hier die Verzögerung nicht allzu groß wird. (Das kann man tatsächlich in Laboren müssen und Microsoft macht das auch.

5-15ms

 

Der Codec ist nun an der Reihe, die digitalen Signale zu komprimieren, in die entsprechenden Häppchen aufzuteilen und möglichst schnell zu versenden. Das kostet aber in der Regel mindestens die Paketgröße von 20ms als Verzögerung.

20ms +

 

Netzwerkkarte 1ter Hop
Heute haben wir alle in der Regel ein "geswitchtes" Netz, so dass Kollisionen oder ein durch andere Stationen "belegtes Medium" nicht mehr vorkommen sollte. Auch das früher bekannte "Backpressing" von Switches sollte kaum noch passieren. Aber FlowControl ist weiter hin da und auch andere Programme auf ihrem PC senden natürlich Daten. ein "XCOPY" oder ein Speichern einer größeren Powerpoint sind durchaus ernstzunehmende Störfaktoren. Auch wenn Audio nur viele kleine Pakete sind, so unterbricht es nicht den Versand von 1514 Byte-Datenbanken durch den PC. Da muss dass RTP Paket dann eben warten. Bei 100 MBit sind das aber dann dennoch weniger als 0,15ms und damit zu vernachlässigen. 

 

 

Auch die Übertragung zum Switch und die dortige Weiterleitung ist selbst bei 100 egabBit kein Problem, zumindest wenn genug Bandbreite bereit steht. Stören könnte aber die Empfangsrichtung sein, wenn der Switch die Pakete einfach in der Reihenfolge in die Queue stellt und die kleinen RTP-Paket nicht vorlässt. Beim Senden kann ein Windows Client ja noch selbst die Reihenfolge bestimmen. Dies gilt aber nicht für den Empfang oder die weiteren Hops. Trotzdem belasse ich hier die Latenz bei 0ms

0ms

 

WAN Latenz
Anders sieht das natürlich aus, wenn eine WAN-Verbindung hier mit involviert ist. Hier sind nicht nur die Bandbreiten geringer, was eine höhere durchschnittliche Belastung und damit ein höheres Risiko einer Blockierung mit sich zieht, sondern die "Schrittgeschwindigkeiten" sind auch geringer, d.h. die Bits sein langsamer und länger auf der Leitung unterwegs. Da ist einfach die Physik am Limit, denn selbst mit Lichtgeschwindigkeit braucht es ein Zeit die Bits über lange Strecken zu übertragen. Und dann kommen noch die elektrischen Wandler und Verstärker dazwischen. Aber selbst das sind immer noch kleine Werte im Vergleich zur Laufzeit. Eine 2 MBit Leitung kann 2 Mio Bit/Sek übertragen. Ein ca. 1,5kByte (vereinfacht 15000bit) Paket blockiert so eine Leitung schon für 7,5ms und wenn der Schedule dann zwischen "großen Daten" und kleinen Audiopaketen einfach numerisch 1:1 tauscht, dann wird es eng für mehrere Audiokanäle. Hier ist also Priorisierung, z.B. nach IP-Ports oder QoS angeraten, wenn sie nicht gleich dedizierte Bandbreite reservieren. Aber selbst ein ca. 200Byte (=2000bit) großes RTP-Paket braucht immer noch 1ms im idealen fall

1+x ms

 

Die Jitter-Queue beim Empfänger
Wenn wir nun auch den Switch und das LAN beim Empfänger außen vor lassen, dann landet das Paket direkt im IP-Stack und wird hier erst mal nicht direkt wiedergegeben. Der Codec muss ja zum einen die empfangenen Pakete eventuell erst in die richtige Reihenfolge bringen und da er auf unterschiedliche Laufzeiten reagieren muss, "verzögert" er absichtlich die Wiedergabe, um Spätankommer noch "in time" abspielen zu können. Dieser Buffer variiert von Codec zu Codec. Einige haben einen statischen Wert und andere passen den Buffer an die Qualität an. In der Regel werden aber immer mindestens 1-2 Pakete im Vorlauf gehalten und beim Einsatz einer Fehlerkorrektur noch mehr. Wenn wir mal davon ausgehen, dass ein Paket wieder 20ms von 160 Samples enthält, dann ist allein der Empfänger für eine Verzögerung von 40-60ms verantwortlich.

40-60ms +

 

Dekomprimierung und Wiedergaben
Die umwandlung der Daten in Töne und die Wiedergabe über ein Headset oder Lautsprecher unterliegt den gleichen Bedingungen wie die Aufnahme. Analoge Lautsprecher an einer PCI-Soundkarte haben weniger Latenzzeiten als USB-Geräte aber in der Regel bewegen sich diese auch im kleinen ms-Bereich

ca 4ms

 

Auch wenn nicht alle Zahlen repräsentativ sind und mit einfachen Mitteln gemessen werden können, so sollten Sie für eine gute Sprachqualität die verschiedenen kniffligen Punkte können und nicht leichtfertig an der ein oder anderen Stelle einen Kompromiss eingehen.

Das müssen von solchen Latenzzeiten ist zum einen schwer, weil es sehr kurze Zeiten sind und einzeln nicht mit dem menschlichen Gehör ermittelt werden können. Der Aufbau einer Schleife, bei der auf der Empfängerseite das erhaltene Signal einfach wieder zum Sender zurück gesendet wird um dort dann die Summe beider Richtungen zu müssen, scheitert meist an der sehr guten Echo Cancellation der RTAudio-Codecs. Über Programme wie "virtual Audiocable" können Sie sowohl solche Schleifen als auch Verbindungen zu Analyseprogrammen "schalten" aber der Messaufbau ist alles andere als Repräsentativ.

Wenn Sie ein "gutes" Headset und einen halbwegs aktuellen PC verwenden und Virenscanner, Firewalls etc. ihnen nicht dazwischen funken, dann können Sie sich fast immer auf das Netzwerk konzentrieren. Und hier liefern zum einen Lync mit dem Monitoring-Service schon sehr viele Werte und wenn QoS nicht die messingen verfälscht, kann auch die Laufzeit eines einfachen PING mit z.B. 200 Bytes als Nutzlast eine erste Abschätzung geben.

Netzwerk simulieren

Nicht jeder hat verschiedene Bandbreiten zur Simulation zur Verfügung. Und es gibt auch immer weniger PCs, die noch einen COM-Port haben, über den sich zwei Systeme mit einem DFÜ-Netzwerk (RAS als Router) mit unterschiedlichen Bandbreiten verbinden lassen. Und selbst dann kann man nur mit einer relativ fixen Bandbreite arbeiten aber unterschiedliche Latenzzeiten oder Paketverluste lassen sich damit kaum simulieren.

Aber es gibt Abhilfe. So enthält Visual Studio 2010 angeblich eine Netzwerkbremse, die ein langsames Netzwerk auf dem PC simuliert:

In verschiedenen Laboren habe ich das Programm NEWT gesehen (Network Emulator für Windows Toolkit), welches leider wohl nicht mehr frei ist. Es ist wohl Teil des Games für Windows LIVE SDK und XBOX XDK, die beide nicht kostenfrei sind. (Quelle: http://blogs.technet.com/b/juanand/archive/2010/03/05/standalone-network-emulator-tool.aspx). Die folgende Seite listet NEWT als ein Produkt auf, welches von MS Research in ein kommerzielles Produkt gewändert ist

Es gibt aber natürlich echte Programme, die einen "Router" simulieren und dort steuern eingreifen können, z. B.

Weitere Links