High-End Lan-Kabel

Wir reden hier immer noch von TCP/IP und Netzwerk und da erklär du doch mal was da in Bezug auf den Endpoint bei der Übertragung jittert so das man am Endpoint das berücksichtigen müsste.
In deiner Welt ist vermutlich das Problem Bufferunderun eines, das man heute noch nicht richtig im Griff hat

Jakob1863,

du tust ja gerade so als währe TCP/IP erst seit kurzem im Betrieb und es gäbe da noch viele technologische Probleme. So leid es mir für dich tut aber diese Technik ist gut erprobt und funktioniert sehr gut. Irgendwie habe ich das Gefühl technisches Verständnis ist nicht deine Stärke.

Hallo,

typisches Layer 8 Problem...

Peter

ZeeeM schrieb:

Wenn die Datenrate permanent unter dem Soll bleibt, dann reisst der Stream halt ab, was denn auch sonst?

... schade, dann ist eine bitidentische Übertragung auch bei IP nicht garantiert, wenn dieser Fall eintritt.

Die Verbindung muss einfach in der Lage sein im Mittel mehr Daten zu transportieren als am Ziel notwendig ist, dann kann das Zielsystem die Quellen auch steuern.

In der "Lage" ist Fast- oder Gigaethernet natürlich, eine höhere Bitrate zu liefern, als für CD-Qualität nötig ist, das ist doch gar nicht in Frage. Der limitierende Schritt ist doch wie beschrieben die Samplerate der Audioquelle, die im Beispiel dauerhaft geringfügig kleiner, als am DAC der Gegenstelle sein kann. Da würden Dir selbst 10-Gigabit-Links nichts nützen.

Es geht ja um ein Prinzip und nicht um spezielle Daten und Programme.

... doch, es geht um spezielle Audioanwendung (deshalb wie gesagt das konkrete Beispiel) und eben nicht um Allgemeinplätze zu TCP/IP und LAN-Interfaces.

Puffer in 0,nix gefüllt

... das geht ebenso am Problem vorbei. Die Audioquelle kann ja auch eine Live-Darbietung sein, und da sind die Audiodaten erst in dem Moment verfügbar, wenn sie gespielt werden. Wenn dann der Recordingsampler dauerhaft zu langsam oder dauerhaft zu schnell ist, kriegt die Gegenstelle ein Problem, denn sie ist ja nicht synchronisiert.

@Jakob1863

Vielen Dank, Du bist mal wieder der Einzige, der sachliche und weiterführende Beiträge schreibt!

@Hörschnecke

du beschreibst ein theoretisches Problem, dass in der Praxis quasi nicht vorkommt, und wenn doch BEKOMMT ES JEDER UNTER GARANTIE mit ( egal ob Holzohr oder Goldohr ). Also was soll das ganze sinnieren a la hätte hätte Fahrradkette.

Und bei BITIDENTISCH liest du bitte nochmal bei TCP/IP nach, könnte helfen, dieses Übertragungsverfahren zumindest in Grundzügen zu verstehen.

Was soll das Gerede, wenn die Audioquelle die Daten langsamer liefert, als die Gegenstelle erwartet? Dann sollte man ein 400€ LAN-Kabel nehmen, damit es zumindest nicht jittert ( frei nach J. ) ? Also ICH würde das Problem am unterdimiensionierten Sender suchen und das Problem an der Quelle beheben... Wie gesagt, theoretisch fliegt uns morgen ein Komet auf den Kopf und wir können jetzt auch diskutieren, wie wir das theoretisch verhindern können.. oder auch nicht.

Hörschnecke (Beitrag #205) schrieb:

... schade, dann ist eine bitidentische Übertragung auch bei IP nicht garantiert, wenn dieser Fall eintritt.

Deswegen erwähnte ich ja auch TCP

Ach und Samplerate und Datenrate solltest du nicht verwechseln.

Wenn Samples ausgelassen oder wiederholt werden müssen, dann ist eine Audiodatenübertragung nicht mehr bitidentisch. Auch wenn Du rumschreist, MaTel - es ändert nichts.

Im Übrigen ist ein abweichender Takt von zwei digitalen Audiogeräten nichts Ungewöhnliches und einer der Gründe, warum es Taktnachführung oder "Haustakt" gibt.

@ZeeeM
Es geht um die effektiv wiedergegebenen Audiodaten (Sample+Zeitfaktor). Der Overhead interessiert nicht.

Hörschnecke (Beitrag #209) schrieb:

@ZeeeM Es geht um die effektiv wiedergegebenen Audiodaten (Sample+Zeitfaktor). Der Overhead interessiert nicht.

Nein, es geht um Netzwerktechnik. TCP/IP garantiert die Datenintegrität, die Buffer das ´Timingprobleme nicht auftreten und dann diktiert die Uhr im Endpoit die Qualität der DA-Wandlung. Auch das Livestreaming hat man in den Griff. Schon mal einen Netzwerkstream mit einer DVBS-Übertragung verglichen. Da wird üppig gepuffert.

Was bedeutet "Es geht um die effektiv wiedergegebenen Audiodaten (Sample+Zeitfaktor). Der Overhead interessiert nicht."
in Bezug auf Übertragung von Audiodaten über TCP/IP. Was wäre denn uneffektiv und warum sollte dann ausgerechnet Overhead nicht mehr interessieren? Weil der Puffer den verschwinden lässt ...

Du hast doch selbst geschrieben, ZeeeM, daß die Datenintegrität verloren geht, wenn permanent weniger Audiodaten als nötig nachkommen (und der vorhandene Buffer hat dieses Timingproblem dann ja wohl nicht verhindert):

Zeeem schrieb:

Wenn die Datenrate permanent unter dem Soll bleibt, dann reisst der Stream halt ab, was denn auch sonst?

Du widersprichst Dir eigentlich nur selbst, ZeeeM.

Dunning-Kruger, was sonst?

Lesen und Verstehen: http://www.crn.de/server-clients/artikel-84415-4.html

Frohe Feiertage.

Hörschnecke (Beitrag #206) schrieb:

@Jakob1863 Vielen Dank, Du bist mal wieder der Einzige, der sachliche und weiterführende Beiträge schreibt!

Und Schweine können fliegen

Hörschnecke begreift nicht ganz, dass selbst dann ein TCP/IP Übertragung BITIDENTISCH ist, wenn die Datenübertragung ( theoretisch ) Tage braucht, nur um ein paar Daten zu übertragen... Ja, da jittern das eine Pakete zweimal um die Sonne und das nächste nur einmal um den Mond und wieder zurück und am Ende kommt immer das wieder an, was am Anfang reingeworfen wurde, weil das TCP/IP Protokoll dafür sorgt. Ist für Livestreams natürlich unbrauchbar... ach. Aber in meinem Netzwerk ist der Weg glücklicherweise nur so ca. 1/2 Meter vom Streamer zum D/A Wandler... liegt zwar ein "ominöser" Switch/Router dazwischen, aber die Pakete kommen, obwohl ich oder wer auch immer in der Familie dabei Surfen oder einen weiteren Stream vom gleichen Streamer abrufen, nahezu verzögerungsfrei und ohne Aussetzer am Ziel an. Da kann man noch so viel mit hätte wäre wenn diskutieren... dat is so.
Bei Liveübertragungen über sehr lange WANs muss der Puffer entweder entsprechend groß sein UND man muss mit damit leben, dass mein Nachbar schon 1 min. vor mir das Tor bei einem Fußballspiel sieht ( weil er analog terristrisch empfängt... ), oder man muss mit Bild- / Tonaussetzter leben, weil Daten verworfen werden nur um möglichst zeitnah einen Livestream von wo auch immer aus dem WAN zu sehen.

MaTel, du kannst den Faktor "Echtzeit" auch total herausnehmen, indem Du eine Audiodatei speicherst, archivierst und sie meinetwegen einige Jahre später per IP auf einen anderen Rechner kopierst. Natürlich geht sowas bitidentisch, das weiß doch jedes Kind.

Genau um dieses Extrem drehte sich meine ursprüngliche, kleine Anfrage aber ganz und gar nicht, sondern wenn schon eher um das genaue Gegenteil: Ein Stream von Audiodaten gehobener Qualität, soweit möglich in Realtime über IP und was das für Implikationen bzgl. Taktung aufwirft. Offenbar herrscht aber selbst in dieser hintersten Schmuddelecke des Forums (Voodoo-Club) ein mittlerweile so destruktives Klima, daß selbst einfache technische Grenzfälle nicht mehr gedacht und diskutiert werden können. - Nichts für ungut, wäre ja wenigstens noch eine Erkenntnis am Ende dieser kleinen Episode.

@Hörschnecke

was ist denn daran nicht zu verstehen, dass solange der Zielpuffer nicht leerläuft es keine Probleme gibt, egal ob es sich um Audiodateien mit gehobener Qualität handelt, oder um das billigste totkomprimierte Musikstück.
100MBit ist dafür ausreichend an Geschwindigkeit. Man kann natürlich diese Datenübertragung mit allerlei "Nebensachen" Surfen, Youtubevideos schauen, IP-TV schauen, Torrent, was weis ich, stören, so dass die Bandbreite irgendwann an die Wand gefahren wird und die Audiodaten nur noch tröpfchenweise am Ziel ankommen und dort der Puffer leerläuft. Konsequenzen sind dann deutlich hörbare Aussetzer, weil der D/A Wandler dann nunmal keine Daten hat, die es zu wandeln gilt. Es spiel sich nicht in den Bereich ab, a la kleinere Bühne, Schleier vor den Boxen, etc. pp. ab.
100mbit/s ( vermutlich im Heimbereich noch die Standardgeschwindigkeit bezüglich Ethernet ) entsprechen theoretisch ( da Rohdaten ) ca. 12Megabyte/s ( ich hoffe, ich habe richtig umgerechnet ). Da muss also einiges los sein im Netz, bis Audiodaten nicht mehr rechtzeitig am Ziel ankommen. Eine komplette FLAC Datei mit mehreren Minuten Inhalt würde binnen paar Sekunden am Ziel sein. Bei Livestreams, völlig egal in welcher Qualtät, "merkt" die Anwendung, wann ihr Puffer leer läuft und fordert weitere Datenpakete vom Sender an, so dass der Puffer im gut gefüllt ist. Falls das, wie oben beschrieben, durch mangelnde Bandbreite nicht möglich ist... tonaussetzer. Das ganze Pakete anfordern und Empfangen spielt sich in einer Geschwindigkeit ab, dass der Hörer die Latenz, die immer dabei entsteht gar nicht mitbekommt.

Ich verstehe auch nicht, was da so schwer zu verstehen ist. So lange Daten im Puffer sind, werden sie gelesen und da gibt es qualitativ nichts zu verbessern. Und falls der Puffer leer ist, wird nichts gelesen, dann kommt auch nichts mehr raus, was sich qualitativ verbessern ließe. Dann knackt, gluckst oder rumpelt es kurz und dann ist Stille. Und ein Livestream ist so gesehen eben auch nicht live, weil Millisekunden zeitversetzt.

Wo soll jetzt da der "Grenzfall" sein? Der Moment, in dem der Puffer geraaaade kurz davor ist, leer zu laufen und just als es geraaade anfangen will zu knacksen, glucksen oder rumpeln, kommt geraaade noch rechtzeitig bzw. geraaaade nicht mehr rechtzeitig das neue Datenpaket an?

Hm, interessante Überlegung, wie sich das anhört, wenn das (vor allem häufiger) passiert. Aber wodurch sollte das so geschehen? Und vor allem: Welchen Einfluss sollte das zuleitende Kabel darauf haben?

Vielleicht hilft ein bildhafter Vergleich: Der D/A-Wandler ist eine Fabrik, die am laufenden Band aus Bausätzen, die in Kisten geliefert werden, Produkte zusamenbaut und an der Warenausgabe ausgibt. Der Puffer ist das Materiallager, das Kabel der Spediteur, der die Bausätze liefert. Es ist völlig Wurscht, ob der die Kisten in schnieken, hochmodernen, tip top gewarteten LKW oder in schrottreifen Schleudern transportiert. So lange unbeschädigte Bausätze im Lager ankommen, kommen an der Warenausgabe Produkte in gewohnter Qualität raus.

Naja,

Hörschnecke meint ja, dass sein Audicity auf dem Server und seine Soundkarte auf dem Client mit unabhängig laufenden Sample- bzw. Datenraten laufen.
Also, z.B Audiacity läuft mit 44098Hz und gibt mit dieser Rate Samples ans Netzwerk ab.
Und seine Soundkarte am anderen Ende der Netzwerksverbindung spielt die empfangenen Daten mit 44103Hz ab, was dann zwangsläufig zu Aussetzern führen muss, nicht wahr.

So ähnlich ist das ja auch im PC selber geregelt, wenn man Audio abspielt:
Die Festplatte bzw. die Mediaplayersoftware liefert die Audiodaten mit einer Rate von z.B. 44,099kHz, während der eingebaute DA-Wandlerchip die Daten mit einer Rate von 44,105kHz wandelt. Deswegen kommt es dann immerwieder zu Datenausetzern, und deswegen klingt Digital immer so steril und kalt.

Nur analog kann man einen kontinuierlichen zeitrichtigen Echtzeit-Audiodatenstrom realisieren.

Grüße

Das wirklich Lustige hier ist doch, wie krampfhaft ein Problem herbeigeredet wird, wo gar keins ist. Also, ich mach das immer anders: Wenn ein Problem da ist, überlege ich mir, wodurch es vielleicht verursacht wird, dann erprobe ich diese Hypothese, und wenn ich falsch gedacht habe, was halt leider oft vorkommt, denke ich noch mal nach. Und gucke. Und denke. Und dann noch mal. Und dann noch mal... Kann schon dauern.
Wenn aber gar kein Problem da ist, warum soll ich dann die Pferde scheu machen?
Ich kann mir richtig vorstellen, wie die armen HaiEnderlein vor ihrer schönen "Kette" sitzen und wie die Schießhunde aufpassen, dass ja die Bühne nicht enger wird, oder der Hochton angestrengt, oder der Bass grau statt "pechschwarz" und wie sie dann hektisch Kabelchen umstecken und LAN-Adressen ändern und Klangschälchen verschieben und Energetisierungschips aufbeppen, anstatt einfach mal 'ne Pause zu machen oder einen Spaziergang, ein Verfahren, welches die oben genannten Probleme weit zuverlässiger lösen würde. Es gibt natürlich noch andere Möglichkeiten, die ich in einem familienfreundlichen Forum aber nicht nennen kann <hüstel>.
Anyway, die Goldohren haben es nicht leicht, das sehe ich schon. Und teuer ist der ganze Sch§$% ja auch noch.

Pigpreast (Beitrag #217) schrieb:

Hm, interessante Überlegung, wie sich das anhört, wenn das (vor allem häufiger) passiert. Aber wodurch sollte das so geschehen? Und vor allem: Welchen Einfluss sollte das zuleitende Kabel darauf haben?

Dazu müsste Abriss des Streams und die Wiederaufnahmen des Streams mit eine Frequenz passieren, die in einem Bereich liegt, das es zu Rauschen oder hörbaren Seitenbänder des Signals kommt. Wüsste nicht wie man das regeln sollte.

Wenn der Puffer als Ringpuffer ausgeführt wird, dann kann es passieren das man es mitbekommt, das der Puffer ein Ringpuffer ist.

Und ganz, ganz wichtig: Bitte unbedingt nicht genutzte LAN Buchsen am Router mit einem Nano Shield Plug abschliessen.

Ein ganzheitliches High Tech Entstörprodukt, das weltweit einmalig ist.

Vermute ich auch mal! Die Seite kannte ich noch gar nicht. Da gibts massenhaft den richtig harten Stoff Unglaublich....

An einem anderen Ort kann man das sogar hören!
Weil:

Entscheidend ist das Ergebnis, und da hab ich echt gestaunt.

über was auch immer...

Frohe Ostern allerseits....
Meiler

Burkie (Beitrag #218) schrieb:

So ähnlich ist das ja auch im PC selber geregelt, wenn man Audio abspielt: Die Festplatte bzw. die Mediaplayersoftware liefert die Audiodaten mit einer Rate von z.B. 44,099kHz, während der eingebaute DA-Wandlerchip die Daten mit einer Rate von 44,105kHz wandelt. Deswegen kommt es dann immerwieder zu Datenausetzern, und deswegen klingt Digital immer so steril und kalt. Nur analog kann man einen kontinuierlichen zeitrichtigen Echtzeit-Audiodatenstrom realisieren. Grüße :prost

Ist völlig egal. Medienplayer füllen einen Puffer und haben selbst überhaupt keinen Takt. Der "Takt" mit dem der Medienplayer läuft ergibt sich nur aus dem Füllen des Puffers. Der Auslesetakt kommt entweder von einem Quarz auf der Soundkarte oder von einem externen Taktgeber über SPDIF / AES EBU oder einem einfachen Masterclock Eingang.

Zeitrichtigkeit und Analog. Dass ich nicht lache. Da gibts definitiv mehr Probleme mit nicht mittig gepressten Schallplatten oder leicht unrund laufenden Capstanwellen.

Um zum Streaming Beispiel zurück zu kommen. Einfach beide Soundkarten mit Masterclock Generatoren syncronisieren. Viele Geräte haben die Möglichkeit das DCF-77 Signal als externen Takt zu nehmen. Damit sollte zumindest in Mitteleuropa ein Auseinanderlaufen der Geräte verhinderbar sein.

Burkie (Beitrag #218) schrieb:

Naja, Hörschnecke meint ja, dass sein Audicity auf dem Server und seine Soundkarte auf dem Client mit unabhängig laufenden Sample- bzw. Datenraten laufen. Also, z.B Audiacity läuft mit 44098Hz und gibt mit dieser Rate Samples ans Netzwerk ab...

Dann verstehe ich aber trotzdem nicht, wie es da zu Problemen kommen sollte, die man mit einem tollen Kabel beheben/verringern kann. Entweder er (sie?) erklärt mir, wo ich etwas nicht verstanden habe bzw. wo mein Vergleich hinkt, oder ich muss weiter davon ausgehen, dass er etwas nicht versteht.

Und was das mit "hinterste Schmuddelecke" und "destruktivem Klima" zu tun haben soll, verstehe ich schon zweimal nicht.

Hörschnecke (Beitrag #206) schrieb:

@Jakob1863 Vielen Dank, Du bist mal wieder der Einzige, der sachliche und weiterführende Beiträge schreibt!

immerhin sind wir da schon zu zweit.

@ MaTel & ZeeeM,

das liest sich so, als sei "irgendwie TCP/IP" bereits ein Allheilmittel. Wenn die Übertragung in Hörschneckes Fall (oder auch generell bei der Audio/Video-Wiedergabe, deshalb hatte ich doch die AVB-Geschichte erwähnt) nun tatsächlich per TCP abliefe, dann gäbe es in der Tat mit hoher Wahrscheinlichkeit keine Datenfehler. UDP gehört nun einmal auch zum "TCP/IP-Protokollstack" und dabei ist keineswegs die "Bitidentität" gesichert, nur weil "TCP/IP draufsteht" .

Da man aber nun gerne Einfrieren, Knackser oder Aussetzer bei hochqualitativer Wiedergabe vermeiden möchte, und zusätzlich um den möglichen Einfluss von Jitter auf die Wiedergabequalität weiß, macht man sich auf allen Ebenen Gedanken darüber, wie man innerhalb des bestehenden Systems eine Lösung finden kann. Ihr könntet euch doch einmal bei der ISO 802- Gruppe umschauen, und euch die Frage stellen, weshalb man sich dort überhaupt Gedanken über AVB gemacht hat, wenn "irgendwie TCP/IP" doch bereits ausreicht, um sämtliche Problemfälle zu umschiffen. Wie geschrieben ist der Gedanke dahinter, einerseits die Voraussetzungen für hochqualitative Übertragungen zu schaffen und andererseits die, in der Zwischenzeit entstandenen proprietären Lösungen oder offenen Standards (Ethersound, Cobranet, Ravenna, AES51, Dante usw. usf.) einzufangen.

Um beim "bildhaften Pigpreast" zu bleiben; in vielen Fällen reicht es halt aus, wenn am Ende des Tages 1000 fertige Kisten herauskommen, in manchen Fällen sollen zwar am Ende des Tages ebenfalls 1000 Kisten herauskommen, aber jede Kiste darf nur _exakt_ einen 1000stel Tag in Anspruch nehmen.

Die Frage war, welchen Einfluss die Qualität der LKW des Spediteurs darauf hat, so lange das Lager nicht leer ist.

Moin

Da man aber nun gerne Einfrieren, Knackser oder Aussetzer bei hochqualitativer Wiedergabe vermeiden möchte, und zusätzlich um den möglichen Einfluss von Jitter auf die Wiedergabequalität weiß, macht man sich auf allen Ebenen Gedanken darüber, wie man innerhalb des bestehenden Systems eine Lösung finden kann.

Wenn man nun also Mord, Folter oder Waterboarding bei hochqualitativer Sicherungsverwahrung vermeiden möchte, und zusätzlich um den möglichen Einfluss der Mondphasen auf die Psyche weiss, macht man sich auf allen Ebenen Gedanken, wie man innerhalb des bestehenden Systems eine Lösung finden kann.

Das leuchtet selbst mir ein..

@preast

2 Idioten, ein Gedanke

Und zwar bei gleich zwei Gedanken. Mir war nämlich auch aufgefallen, dass eindeutig erkenn- und erklärbare Einfrierer, Knackser oder Aussetzer in einem Atemzug mit subtilen, angeblich (und auf im Zusammenhang mit Kabeln immer noch nicht erklärte Weise) durch Jitter verursachten Qualitätseinbußen genannt wurden. Mir schien der Versuch, Letzteres mit Hilfe des Ersten zu verkaufen, nur so plump, dass ich ihn Jakob nicht zutraute und ich erst einmal in mich gehen musste, um zu prüfen, ob ich etwas falsch verstanden hatte.

Pigpreast (Beitrag #225) schrieb:

Die Frage war, welchen Einfluss die Qualität der LKW des Spediteurs darauf hat, so lange das Lager nicht leer ist.

Mit Verlaub; die Frage taucht doch erst dann auf, wenn man sich von dem falschen Argument "irgendwie TCP/IP reicht schon aus" gelöst hat, nicht wahr?

Irgendwo in diesem Thread hat sich jemand "beömmelt" weil eine Zeitschrift die Übersprechdämpfung gemessen hat (vermutlich weil der Betreffende die Idee bereits absurd fand), aber in der Realität ist bekanntermaßen das Übersprechen eine mögliche Ursache für die Qualitätsbeeinflussung (in dem Fall Jitter)....

Hörschnecke hat aber nun die Frage nach dem Umgang mit Timing-Problemen aufgeworfen und der Jakob1863 andererseits schrieb vor einiger Zeit in diesem Thread, dass es auf elektrotechnische Probleme hindeute, wenn der Austausch eines Kabels zu einer wahrnehmbaren Veränderung führe und man überhaupt sinnvollerweise erstmal ein paar Messungen sowie vernünftige Hörttests durchführen solle. (Was er übrigens auch schon in dem verlinkten, 4 Jahre zurückliegenden Thread zu den USB-Jitter etc. schrieb)

@ kinodehemm,

vielleicht hattest du zwischendurch - "glaubensbedingt" vermutlich - den Überblick verloren, aber sowohl MaTel als auch ZeeeM argumentierten damit, dass es innerhalb des "Systems" (aka TCP/IP) überhaupt kein Problem geben könne (eben weil TCP/IP) und dieser Standpunkt wird durch das intensive Bemühen innerhalb der ISO 802 - Gruppe, hochqualitative Wiedergabe _sicherzustellen_ konterkariert.
Anders gesagt, innerhalb der ISO 802 - Gruppe wusste/weiss man halt, dass "irgendwie TCP/IP" nicht ausreicht/ausreichte, und hat deshalb die Standards erweitert; leuchtet hoffentlich auch dir ein?!

@ Pigpreast,

wo ich gerade deinen Nachtrag lese; beschränke dich doch einfach darauf, zu verstehen, was explizit geschrieben wurd. In diesem Thread werden halt mehrere Punkte gleichzeitig behandelt und bekanntermassen liegst du beim Fantasieren über "was alles noch gleichzeitig subtil oder nicht subtil mitbehauptet werden sollte" iaR daneben.

Jakob1863 (Beitrag #228) schrieb:

Mit Verlaub; die Frage taucht doch erst dann auf, wenn man sich von dem falschen Argument "irgendwie TCP/IP reicht schon aus" gelöst hat, nicht wahr?

Es gibt eine Menge an Leuten, die glauben ganz ganz ganz fest daran verstanden zu haben warum etwas nicht sein kann.
TCP/IP ist kein Argument gegen Jitter im Netzwerkbetrieb

Pigpreast (Beitrag #223) schrieb:

Burkie (Beitrag #218) schrieb: Naja, Hörschnecke meint ja, dass sein Audicity auf dem Server und seine Soundkarte auf dem Client mit unabhängig laufenden Sample- bzw. Datenraten laufen. Also, z.B Audiacity läuft mit 44098Hz und gibt mit dieser Rate Samples ans Netzwerk ab... Dann verstehe ich aber trotzdem nicht, wie es da zu Problemen kommen sollte, die man mit einem tollen Kabel beheben/verringern kann. Entweder er (sie?) erklärt mir, wo ich etwas nicht verstanden habe bzw. wo mein Vergleich hinkt, oder ich muss weiter davon ausgehen, dass er etwas nicht versteht. :?

Das ist doch im Prinzip ganz einfach: Man braucht ein Super-Lan-Kabel mit einer Art eingebautem Zobel-Glied, welches die Übertragungsdatenrate über angepasste Wellenwiederstände und komplexe Resonanzen im Skineffekt so erhöht, das die Datenübertragungsrate wieder die Wiedergaberate erreicht.
So oder ähnlich wird dir Jakob oder ein Kabelfachmann das Ganze erklären.

Jakob hat Recht, TCP besteht praktisch nur aus Problemen, es wird sozusagen nur von Problemen zusammengehalten und funktioniert deshalb in der Praxis auch gar nicht. Für jemanden, der moderne Technik nicht versteht, stellt sich das in der Tat so da.

In Hi-End-Kreisen stellt es sich ja ganz häufig so dar: Zuerst ein Problem herbeierklären, und dann durch ungeeignete Massnahmen wie z.B. Super-Lan-Kabel "lösen" - das funktioniert bekanntlich immer .... - weil ja das Problem erst herbeierklärt werden musste.

Grüße

Hallo,

hauptsache der doofe aber solvente Kunde käuft den überteuerten Mist dann auch...

Der doofe arme Kunde sowie der kluge solvente Kunde sind eh keine Zielgruppen.

Da kann der Herr Nebelbombenentwickler soviel Probleme erfinden wie er lustig ist.

Peter

Bei dieser Endlosschleifen-Fachsimpelei hier dauert das ja noch glatt Jahrzehnte, bis endlich ein wirklich gut klingendes Audio LAN- Kabel erfunden worden ist. Diese Entwicklung muss natürlich irgendwie finanziert werden. Allein aus diesem Grunde gibt es heute schon High-End LAN - Kabel.

Jakob1863 (Beitrag #228) schrieb:

Pigpreast (Beitrag #225) schrieb: Die Frage war, welchen Einfluss die Qualität der LKW des Spediteurs darauf hat, so lange das Lager nicht leer ist. Mit Verlaub; die Frage taucht doch erst dann auf, wenn man sich von dem falschen Argument "irgendwie TCP/IP reicht schon aus" gelöst hat, nicht wahr?

Ja, natürlich. Aber wie ist denn dann die Antwort? Genau wie ich es an Hörschnecke adressierte, meine Bitte nun an Dich: Erkläre es mir anhand meines Bildes oder erkläre mir, wo mein Vergleich hinkt.

...beschränke dich doch einfach darauf, zu verstehen, was explizit geschrieben wurd. In diesem Thread werden halt mehrere Punkte gleichzeitig behandelt und bekanntermassen liegst du beim Fantasieren über "was alles noch gleichzeitig subtil oder nicht subtil mitbehauptet werden sollte" iaR daneben.

Getroffene Hunde bellen.

Falls dem nicht so ist, kannst Du Dich ja auch darauf beschränken, meiner geäußerten Bitte nachzukommen.

Hallo,

uiuiui, Fakten .... die sind gerade aus. Sind leider nur Nebelbomben da

Peter

Komm, wir müssen den Jakob etwas in Schutz nehmen. Wer weiss, was er so täglich online zu lesen bekommt. Bei den ganzen fehlerhaften Bits und Bytes die er über das TCP/IP aus dem WAN erhält, bekommt er evtl. was völlig anderes bzw. sinnentstelltes zu lesen, als wir Normalsterblichen Von den ganzen Instabilitäten durch ständigen defekten Downloads bzw. Systemupdates ganz zu schweigen, da bei ihm gekippte oder fehlende oder zugedichtete Bits ja der Normalzustand zu sein scheint.

@Jakob
PS: UDP ungleich TCP. Beide Protokolle gehören zur Transportschicht des IP ( Internetprotokoll ). UDP ist dabei unsicher und fehlerbehaftet ( bei stabiler Verbindung KANN es auch fehlerfrei sein ). TCP ist immer sicher, da hier in der Transportschicht schon die Datenintegrität geprüft wird und gegebenenfalls Pakete neu angefordert werden.

MaTel (Beitrag #235) schrieb:

<snip> @Jakob PS: UDP ungleich TCP. Beide Protokolle gehören zur Transportschicht des IP ( Internetprotokoll ). UDP ist dabei unsicher und fehlerbehaftet ( bei stabiler Verbindung KANN es auch fehlerfrei sein ). TCP ist immer sicher, da hier in der Transportschicht schon die Datenintegrität geprüft wird und gegebenenfalls Pakete neu angefordert werden.

Donnerwetter
Aber ansonsten lag darin genau der Grund weshalb ich an MaTel & ZeeeM vschrieb, denn der eine meinte:

Nein, es geht um Netzwerktechnik. TCP/IP garantiert die Datenintegrität, ......

während der andere beisteuerte:

.....begreift nicht ganz, dass selbst dann ein TCP/IP Übertragung BITIDENTISCH ist.....

und deshalb wars an beide gerichtet:

@ MaTel & ZeeeM, das liest sich so, als sei "irgendwie TCP/IP" bereits ein Allheilmittel. Wenn die Übertragung in Hörschneckes Fall (oder auch generell bei der Audio/Video-Wiedergabe, deshalb hatte ich doch die AVB-Geschichte erwähnt) nun tatsächlich per TCP abliefe, dann gäbe es in der Tat mit hoher Wahrscheinlichkeit keine Datenfehler. UDP gehört nun einmal auch zum "TCP/IP-Protokollstack" und dabei ist keineswegs die "Bitidentität" gesichert, nur weil "TCP/IP draufsteht" .

Mir also das zu erklären, was ich dir vorher schrieb, mutet irgendwie merkwürdig an.....

UDP gehört nun einmal auch zum "TCP/IP-Protokollstack" und dabei ist keineswegs die "Bitidentität" gesichert, nur weil "TCP/IP draufsteht" .

Ja, Jakob, das unterschreibst du sicherlich so, oder?

Und was verstehst DU daran ncht?

Ich verstehe schon was zum Layer 4 im OSI-Modell gehört und das TCP Datenintegrität sichert. Was verstehst DU denn nicht?

Thema verfehlt, es geht um Audiodaten.

Frohe Ostern allerseits.

Wie ich sehe legt Jakob mal wieder ein Ei nach dem anderem ins Nest.

Er möchte wohl, dass wir ihm auch noch die Eier für ihn ausbrüten.

Jakob entweder UDP/IP oder TCP/IP !

Der wichtigste Unterschied zwischen TCP und UDP liegt darin, dass eine Übertragung mit TCP erst dann abgeschlossen ist, wenn der Empfänger den korrekten Empfang aller Datenpakete bestätigt hat, bei UDP hingegen wird der Empfang nicht bestätigt. Vor allem der Umstand, dass fehlende oder fehlerhafte Pakete erneut übertragen werden können, macht TCP ideal für Dateiübertragungen, bei denen alle Daten korrekt ankommen müssen und der Ankunftszeitpunkt keine Rolle spielt. UDP hingegen wurde explizit für Übertragungen in Echtzeit entwickelt, sodass Pakete, die nicht, nicht rechtzeitig oder fehlerhaft ankommen, verworfen werden, da der Ankunftszeitpunkt relevant ist und verzögerte Pakete nicht mehr verwendet werden können.

Daher verwendet HTTP auch TCP/IP und RTSP eher UDP/IP (obwohl es gibt auch RTSP mit TCP/IP).
Bei UDP/IP mag das LAN-Kabel (und Einflüsse von Außen) bei schlechter Eignung zu einer höheren Fehlerrate führen, die ja nicht mehr kompensiert werden kann.
Bei TCP/IP ist das Kabel (sofern es die Spezifikation erfüllt) absolut unwichtig. Und bei WLAN spielt das Kabel erst recht keine Rolle mehr.

Wenn die Session zur Übertragung der Audio-Daten (Streaming) zwischen Quelle und und Senke (Server-Client) nicht in Realtime gesteuert werden muss, sondern stattdessen Datenpuffer beim Empfänger verwendet werden (und somit auch TCP/IP verwendet werden kann) hat es sich für für alle Zeiten "ausgejittert".

hifi_angel (Beitrag #241) schrieb:

Wenn die Session zur Übertragung der Audio-Daten (Streaming) zwischen Quelle und und Senke (Server-Client) nicht in Realtime gesteuert werden muss, sondern stattdessen Datenpuffer beim Empfänger verwendet werden (und somit auch TCP/IP verwendet werden kann) hat es sich für für alle Zeiten "ausgejittert". :D

Wie wird diese Behauptung belegt? Einfach feste drann glauben?

Jakob1863 (Beitrag #236) schrieb:

Mir also das zu erklären, was ich dir vorher schrieb, mutet irgendwie merkwürdig an..... 8)

Du schreibst viel bis sehr viel, nur verstehen tust du das Thema absichtlich? nicht. Keine Ahnung, warum du dann deine eigenen? Behauptungen ( ich vermute eher, das sie irgendwo abgelesen, aber so rein gar nicht verstanden wurden ) dann ins Gegenteil umdeutest, nur damit es wieder in dein nebulöses Weltbild passt.
Habe seit über 20 Jahren mit Netzwerktechnik beruflich zu tun und nur selten so ein Stuß von HighEnd-Ketten Anhängern bezüglich Netzwerktechnik gelesen, wie in diesem Thread/Forum. Mit den Scheinargumenten, wie hier diskutiert wird, wäre das Internet schon 1981 ad acta gelegt worden, weil nur Müll hinten herauskommt. Das pöse WWW wäre nie gekommen und die Quacksalber hätten ihre Ruhe in ihren Geschäften, wo ihnen kein "Heini" in Kundenverarsche ( Kundengespräche ) hineinredet. Technische Publikationen werden von diesen Kunden eh nicht verstanden und von den Verkäufern als Teufelswerk verdammt
Kein Wunder, wenn dann 400€ LAN-Kabel von denen gekauft werden, wenn man ihnen einen Ochs vorm Berg erzählt und diese wie Lemminge irgendwelchem Geschwafel folgen.

Ja, wat is denn nu mit den audiophilen LAN- oder SATA-Kabeln? Wie verbessern die denn nun die Klangqualität?

Jakob schwafelt ja viel..

Fakt ist jedenfalls, dass seine Super-Lan-Netzwerkkabel seine ganze TCP-Problematik wie durch ein Wunder lösen.


Grüße

Ach so. Das verstehe ich natürlich.

samusan (Beitrag #242) schrieb:

Wie wird diese Behauptung belegt?

Na u.a. einfach auch dadurch, dass du keinen negativen Einfluss durch (Kabel-) Jitter aufzeigen kannst, wenn keine Realtime-Anwendung für das Audio-Streaming gefahren wird und TCP/IP mit Puffer auf der Empfängerseite verwendet wird, egal welches LAN-Kabel mit der geforderten Spezifikation du auch verwendest oder sogar gleich WLAN einsetzt.

Wenn der "Puffer" dick genug ist, dann kann man die Daten sogar auf Polykarbonatscheiben pressen, lagern, mit dem LKW durch die Gegend kutschieren und man hört nix vom Transport.

Frohe Ostern,
ich glaub's echt nicht!
Jakob, weißt Du eigentlich, dass du durch deine Übertreibungen immer mehr Anhänger verlierst; -
hatte doch einer in einem anderen Thread geschrieben:
http://www.hifi-foru...19272&postID=140#140
Es muss doch irgendwann gut sein?

Vielleicht gibt es auch noch mehr Leute außer mir, die auch die anderen Schichten des ISO/OSI-Modells bezüglich der Ethernet-Kommunikation verstehen.


Kleiner Hinweis, auch UDP/IP ist nicht unsicher, es hat eine Checksumme!
Ethernet hat eine Hamming Distanz von 5! (MHD=3)
Und außerdem gibt es ja noch Ebenen unterhalb von 4.
Ich sag nur Manchester-Coding!

Frage: Wie stark muss der Ethernet-Übertragungstakt jittern, damit ein Manchester-Codiertes Bit falsch empfangen wird?

Es kann einfach niemals so stark jittern!

Informationen sind also Bitidentisch.

Das Pufferproblem ist gelöst. Es gibt auf Empfänger - und Senderseite Puffer. Bei einem digital übertragenen Life-Fußballspiel sieht man defenitiv das Tor erst später! (Konnte ich selber 2006 beobachten)

Es gibt natürlich Anwendungen (Tonstudio) für die zeitrichtige Aufnahme von Audiodaten mit digitaler Übertragung mit mehr als 2 Quellen, dann reicht TCP/IP nicht mehr, da ja der Original-Audiotakt bei TCP/IP gar nicht übertragen wird.

Und das Firewire-Dokument war ja wohl voll am Thema vorbei.

Interessant ist wie hier einige sich vehement auf ihre rudimentären Netzwerkkentnisse berufen und zu wissen glauben wie es funktioniert - Köstlich.