High-End Lan-Kabel

Jetzt mal was aus dem echten Leben des Audiodaten-Streaming ...

Wie sehen die Audiodaten vorher und nachher aus, nachdem ich sie über ein "High-End Lan-Kabel" sprich 1 m CAT.5 UTP gestreamt habe?

Hier der Versuch: Wieder zwei Laptops verbunden mit dem genannten LAN-Kabel. Testfile der Audioübertragung ist diesmal ein sogenannter Clicktrack, automatisch erstellbar in Audacity. Diesen Clicktrack von etwas über einer Minute spiele ich über Laptop1 ab, übertrage ihn mit jacktrip über das LAN-Kabel und nehme ihn auf der Gegenstelle von jacktrip wieder entgegen und zeichne ihn mit Audacity dort wieder auf. Auf den ersten Blick sehen beide Audiospuren gleich aus, nicht wahr? (die ersten beiden Tracks oben im Bild) ... aber das täuscht!

Wenn man nämlich zum Ende der beiden Tracks geht, stellt man fest, daß der aufgenommene Track länger ist bzw. mehr Samples enthält (Track3 und Track4 von oben).

Die Frage war jetzt, wie finde ich die Abweichungen zwischen Original und dem übertragenen Track? Dazu habe ich beide Spuren am identischen Startpunkt übereinandergelegt und gemixt ("Mix and Render"). Solange die Dateien gleich sind , verdoppelt sich die Amplitude schlicht. Entsteht aber irgendwo ein erster Versatz, addieren sich die beiden Tracks zu einem anderen Muster. Dies ist im Track5 auch zusehen. Die erste Divergenz ist bei ca. 2.5 s zu erkennen und später dann nochmals nach ca. 55 s.

Wenn man an diesen Stellen einzoomt, kann man auch erkennen, daß es eine Systematik gibt. An der ersten Abweichung (Track6, Track7) enthält der aufgenommene Track 128 Samples (!) mehr, und zwar Nullen bzw Stille.

An der zweiten Abweichung grob 50 s später wächst die Abweichung dann abermals um 128 Nullsamples an, auf nun insgesamt 256 Samples (Track8, Track9).

Es bleibt also festzuhalten:

1.) Das Audiodaten-Streaming in nahezu Echtzeit ist nicht bitidentisch gewesen.
2.) Es trat ein Fehler von insgesamt 256 Samples auf.
3.) Es wurde an zwei Stellen "Stille" von jeweils 128 Samples durch einen unbekannten Prozess eingefügt.

Es drängt sich die Vermutung auf, daß es einen Zusammenhang zur verwendeten Puffergröße gibt, welche in jackd auf "128 Frames/Period" eingestellt ist und auch entsprechend von jacktrip als "Audio buffer size 128 samples" beim Start angezeigt wird.

Es bleibt also festzuhalten:

Wirkt sich das alles auf das eigentlich wichtige und interessante aus, dem Klang ?
Wird dadurch ein klanglicher Unterschied generiert ?
Das wäre ja die Hauptsache, das Hauptargument, also ?
Die Nummer mit den Präsentieren von Unterschieden ist wie Fische in einen Fass angeln.
Das wird z.B. gerne von High-End Netzfilter Herstellern genommen...vorher waren die Störungen so groß, jetzt sind sie so groß..
Und nu ?
Sei es Filter, sei es Sicherungen, sei es Kabel ...das Zeug soll doch eine klangliche Verbesserung bewirken.
Sonst brauch ich mir das doch nicht anschaffen.
Also kann man sich den ganzen Pseudo-Erklärungs/Mess-Schmu sparen und es aufs wesentliche, auf den Kaufgrund runterbrechen:
Höre ich damit jetzt besser oder nicht, liegen entsprechend valide Belege vor ?
Ja oder Nein ?
Alles andere ist doch unerheblich.

Hörschnecke,
ist das ein Beweis, dass man eine so komische Konfiguration aufbauen kann, dass Files doch nicht bitidentisch sind?

Hörschnecke (Beitrag #252) schrieb:

Wie sehen die Audiodaten vorher und nachher aus, nachdem ich sie über ein "High-End Lan-Kabel" sprich 1 m CAT.5 UTP gestreamt habe? Es bleibt also festzuhalten: 1.) Das Audiodaten-Streaming in nahezu Echtzeit ist nicht bitidentisch gewesen. 2.) Es trat ein Fehler von insgesamt 256 Samples auf. 3.) Es wurde an zwei Stellen "Stille" von jeweils 128 Samples durch einen unbekannten Prozess eingefügt.

Na, siehst...!
Hätteste mal ein richtiges Super-Hi-End-Lan-Kabel genommen, wäre das alles nicht passiert.
Das falsche Lan-Kabel hat heimlich 128 Samples dazu erfunden.
Das liegt alles am falschen Lan-Kabel...!

Grüße

Ich weiß auch nich. Weder, woher die Samples kommen, noch, was man von denen hören können soll, noch was ein "besseres" Kabel daran ändert. Aber wenn ich danach frage, bekomme ich von entsprechender Stelle wahrscheinlich immer noch keine verständliche Antwort, werde aber beizeiten wieder bezichtigt, nur in der falschen "Glaubenshose" zu stecken...

Hörschnecke,
wie du vielleicht noch weißt, bin ich in der Automatisierungstechnik tätig.
Ich weiß natürlich nicht, was jacktrip da versucht zu machen.
Wahrscheinlich wird eine sogenannte Echtzeitübertragung versucht?
Das klappt normalerweise gerade nicht über eine Ethernet-Verbindung.
Damit man etwas über Ethernet in Echtzeit übertragen kann,
sind ganz besondere Kniffe notwendig, diese sind z.B verwirklicht in den industriellen Ethernet-Protokollen Profinet-IRT und EtherCAT.

Der Trick ist doch gerade, dass ein Stream vom Server keine Echtzeit-Übertragung ist. -
Es wird der original Audio-Takt überhaupt gar nicht mitübertragen, und wo nichts ist, kann auch nichts jittern.

Je kleiner der Puffer in einem System und je kürzer die erforderliche Latentenz, desto eher kann der Datentransport abreissen.
Schlecht geschriebene Implementation von ASIO-Treibern sind ein Beispiel. Das hat alles mit LAN im speziellen nicht zu tun.
Es gibt natürlich beispiele für schlechte, dann defekte LAN-Verkablung. Das z.B. Netzwerkkarten über eine Leitung zwar noch gebacken bekommen das sie Gigabit reden sollen, dann aber die effektive Geschwindkeit im Bereich von wenigen kB./sec. liegt, das kommt auch vor.
Es geht ja nicht um seltene Spezialfälle, die man notfalls auch konstruieren kann, sondern um den Normalbetrieb.

Anmerkung: Echtzeit wird von Otto-Normal-User auch falsch verstanden. Es bedeutet nicht, das etwas sofort passiert, sondern in einem verlässlichen, definierten Zeitrahmen.

bugatti66 (Beitrag #257) schrieb:

Der Trick ist doch gerade, dass ein Stream vom Server keine Echtzeit-Übertragung ist.

Nach der Definition von Echtzeit sollte sich das gesamte System im Normalfall wie ein Echztzeitsystem verhalten. Die Zeitfenster weden da aber nicht von den Daten bestimmt, sondern von den Puffern.

ZeeeM (Beitrag #237) schrieb:

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?

Das habe ich eigentlich bereits zweimal "unterschrieben", denn ich bin der Autor der zitierten Zeilen.....

Deshalb die Frage, hattest du es vergessen/überlesen oder welchen Zweck verfolgte deine Frage?

@ Pigpreast,

getroffene Hunde bellen??
Du hattest doch etwas über mich geschrieben, wie so oft mit "Glaubensanteill"; in diesem Fall, dass ich etwas plump in Zusammenhang gebracht hätte, um......

Ich habe den Zusammenhang so beschrieben, weil innerhalb der 802-Gruppe die Ziele, die mit AVB verfolgt/erreicht werden sollten, genau so beschrieben wurden:

Two key AVB requirements -Guaranteed QoS •Resource reservation and admission control for media streams •Meet jitter, wander, time synchronization and latency requirements of applications •Along with end-to-end requirements, must consider reference model(s) to determine allocation to AVB network

(Quelle: den Hollander, Garner, Ryu - Samsung - ; Präsentation anläßlich des "The 4th International Telecoms Synchronization Forum 2006" )

Jakob1863 (Beitrag #260) schrieb:

ZeeeM (Beitrag #237) schrieb: 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? Das habe ich eigentlich bereits zweimal "unterschrieben", denn ich bin der Autor der zitierten Zeilen..... :)

Ich wollte nur sicher gehen das du von Netzwerktechnik nichts verstehst. Danke für dein Scheitern am Layer 4.

Im Wiki-Artikel Echtzeit ( https://de.wikipedia.org/wiki/Echtzeit ) taucht der Begriff Puffer nicht auf.
Für die Automatisierungstechnik ist von "harter" Echtzeit auszugehen. Es gibt keine Puffer.
Allerdings gib es die Möglichkeit des "Oversampling", aber jetzt schweifen wir ab.

@Hörschnecke,
zur Analyse der Datenübertragung auf dem Ethernet gibt es ein freies Tool, das heißt "wireshark",
das kann man sich herunterladen, auf beiden Rechnern drauf machen, und aufzeichnen, und dann anschauen, ob es an den Problemstellen auch Probleme auf dem Ethernet gab, oder ob die Senderseite von jacktrip, oder die Empfängerseite im Empfangsrechner von jacktrip die Probleme macht.
Denn leider ist das Windows-Betriebssystem auch keine Echtzeit, im Gegensatz zu Speicher-Programmierbaren -Steuerungen (SPS) und Motion-Controllern, die in der Automatisierungstechnik eingesetzt werden.

Hörschnecke (Beitrag #252) schrieb:

Jetzt mal was aus dem echten Leben des Audiodaten-Streaming ...

... mit einem Bastelprogramm, welches ich max. als Semsterarbeit durchgehen lassen würde

Hörschnecke (Beitrag #252) schrieb:

Wie sehen die Audiodaten vorher und nachher aus, nachdem ich sie über ein "High-End Lan-Kabel" sprich 1 m CAT.5 UTP gestreamt habe?

... und mit jedem anderen LAN-Kabel auch ...

Hörschnecke (Beitrag #252) schrieb:

... Wenn man nämlich zum Ende der beiden Tracks geht, stellt man fest, daß der aufgenommene Track länger ist bzw. mehr Samples enthält (Track3 und Track4 von oben). ---

schön , du hast jetzt das gemessen, was dort Jackpit beschrieben wird ...

Also kurz vereinfacht zusammengefasst: das Progrämmchen verschickt die Audio-Daten per UDP-Pakete (bestehend aus z.B. 3 Sample-Paketen) zu anderen Rechnern. Da die Rechner mit unterschiedlichen 'Audio'-Takten arbeiten, kann es Puffer over/underruns geben (schön im PDF beschrieben), was dieses 'tolle' Programm dazu veranlasst in diesem Fall entweder Pakete einfach wegzuschmeissen (overrun, Seite 21) oder null bzw. das letzte Paket nochmals zu schicken (underun, Seite 20). Ausserdem sieht man auch ganz schön, was bei verlorenen UDP-Paketen getan wird (seite 22): es gibt eine einfache Redundanz (3-'Samples'-Paketchen pro UDP-Paket), geht ein UDP-Paket verloren, ist im nächsten Paket das selbe Sample-Paketchen nochmals da. Gehen mehrere verloren -> PP

Und das ganze hat NIX mit Kabel zu tun ....

Soviel mal dazu

Jakob,
AVB ist auch Echtzeit, siehe hier: http://www.linux-magazin.de/Ausgaben/2013/11/AVB

Sie bietet präzise Synchronisation aller Teilnehmer sowie Quality of Service auf der Netzwerkschicht 2. Damit schafft sie die Voraussetzung dafür, digitales Audio und Video in Echtzeit durchs Netzwerk zu schicken.

Echtzeit-Kommunikation steht hier nicht zur Diskussion.

bugatti66 (Beitrag #262) schrieb:

Im Wiki-Artikel Echtzeit ( https://de.wikipedia.org/wiki/Echtzeit ) taucht der Begriff Puffer nicht auf. Für die Automatisierungstechnik ist von "harter" Echtzeit auszugehen. Es gibt keine Puffer.

Das ist schon klar. Der Begriff Puffer brauch man auch nicht, wenn man das Gesamtsystem als Blackbox betrachtet.
Technisch setzen die Puffergrößen aber durchaus die Rahmenbedingung. Gesendetes Datenpaket in 10ms am Wandler oder innerhalb von 5 Sekunden. Kann man in beliebigen Zehnerpotenzen hin- und herskalieren. Ging mir auch nur darum zu sagen, das Echtzeit nicht immer sofort heisst.

ZeeeM (Beitrag #261) schrieb:

Jakob1863 (Beitrag #260) schrieb: ZeeeM (Beitrag #237) schrieb: 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? Das habe ich eigentlich bereits zweimal "unterschrieben", denn ich bin der Autor der zitierten Zeilen..... :) Ich wollte nur sicher gehen das du von Netzwerktechnik nichts verstehst. Danke für dein Scheitern am Layer 4. :D

Na komm, ein bissschen Erklärung musst du jetzt schon liefern.

Der kryptische Satz bedeutet also, wenn man nicht am "Layer 4" scheitert, dann ist die Datenintegrität auf wundersame Weise auch bei UDP gesichert?
Es gibt ja nicht so viele Möglichkeiten, entweder können Datenpakete verloren gehen -> Datenintegrität ist nicht gesichert
oder aber, es können keine Datenpakete verloren gehen -> Datenintegrität ist gesichert

Nur zur Erinnerung, Hörschnecke beschrieb, dass bei Jacktrip UDP-Ports eingerichtet wurden, du bestandst darauf, dass TCP/IP die Datenintegrität auch in dem Fall sicherstelle, legtest nochmal nach, dass du von _TCP_ geschrieben hättest, auf dem die Übertragung basieren würde, obwohl tatsächlich UDP verwendet wird.

Jakob1863 (Beitrag #266) schrieb:

ZeeeM (Beitrag #261) schrieb: Jakob1863 (Beitrag #260) schrieb: ZeeeM (Beitrag #237) schrieb: 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? Das habe ich eigentlich bereits zweimal "unterschrieben", denn ich bin der Autor der zitierten Zeilen..... :) Ich wollte nur sicher gehen das du von Netzwerktechnik nichts verstehst. Danke für dein Scheitern am Layer 4. :D Na komm, ein bissschen Erklärung musst du jetzt schon liefern. ;)

Müssen muß er gar nichts.
Vielehr musst du erstmal nachweisen, wieso denn nun dein tolles Super-Hi-End-Lan-Kabel diese ganzen Probleme, die du herbeigeredet hast, lösen könnte....?


Grüße

Ich habe jetzt die Übertragungsrichtung der gleichen Clicktrack-Datei einmal umgekehrt, diesmal also Audiostreaming von Laptop2 auf Laptop1 via LAN/jacktrip.

Auch hierbei werden die Daten verändert, diesmal ist der digital übertragene Track aber kürzer, als das Original.

Gemäß Bild ist der aufgezeichnete Stream am Ende effektiv um 256 Samples kürzer:



Ein erster Versatz - erkennbar beim Übereinanderlegen von Original und Aufnahme - trat diesmal nach etwa 14 s auf.

Eine erweiterte Deutung anhand dieser Richtungsumkehr könnte nun sein, daß die Samplerate auf Laptop1 etwas geringer, als auf Laptop2 ist. Dann wurde möglicherweise ein leergelaufener Buffer im ersten Versuch mit Nullen überbrückt, bis er wieder gefüllt war. Bei der Richtungsumkehr könnte der Buffer übergelaufen und sein Inhalt verworfen worden sein.

@bugatti66
Du bist erst spät eingestiegen und offenbar nicht auf dem Stand der Diskussion. Mein beiläufige Frage vor vielen Beiträgen drehte sich nicht um Jitter, sondern um Buffer-Underuns bei nicht-synchronisierten Gegenstellen, siehe:

Hörschnecke (Beitrag #197) schrieb:

Nicht ganz gelöst ist für mich die Frage, wie bei einer solchen Entkopplung der Taktung das Problem des langfristigen Pufferüberlaufs bzw. -leerlaufs gelöst wird. Natürlich kann man einen Puffer so groß wählen, daß z.B. eine ganze CD darin Platz hätte, aber das geschieht ja um den Preis der hohen Latenz, um jenen erst zu füllen. Wie vermeiden solche per IP verbundene Systeme, daß z.B. bei einer Liveübertragung in möglichst Echtzeit der Puffer nicht irgendwann leerläuft, wenn das Sendersystem permanent etwas langsamer taktet, als das Empfängersystem?

Das Pufferproblem ist bereits auf der TCP/IP-Schicht 4 gelöst. Es ist der Win-Parameter, kann man auch schön im wireshark ansehen.
https://de.wikipedia.org/wiki/TCP_Receive_Window

Hörschnecke (Beitrag #268) schrieb:

Ich habe jetzt die Übertragungsrichtung der gleichen Clicktrack-Datei einmal umgekehrt, diesmal also Audiostreaming von Laptop2 auf Laptop1 via LAN/jacktrip. Auch hierbei werden die Daten verändert, diesmal ist der digital übertragene Track aber kürzer, als das Original.

Das ist richtig, und liegt auch wieder nur am verwendeten schlechten Kabel!
Mit dem Super-Hi-End-Netzwerkskabel aus dem ersten Beitrag hier wäre das alles nicht passiert...!

Grüße

Jetzt mal dazu

Hörschnecke (Beitrag #197) schrieb:

Nicht ganz gelöst ist für mich die Frage, wie bei einer solchen Entkopplung der Taktung das Problem des langfristigen Pufferüberlaufs bzw. -leerlaufs gelöst wird. Natürlich kann man einen Puffer so groß wählen, daß z.B. eine ganze CD darin Platz hätte, aber das geschieht ja um den Preis der hohen Latenz, um jenen erst zu füllen. Wie vermeiden solche per IP verbundene Systeme, daß z.B. bei einer Liveübertragung in möglichst Echtzeit der Puffer nicht irgendwann leerläuft, wenn das Sendersystem permanent etwas langsamer taktet, als das Empfängersystem?

Hörschnecke (Beitrag #215) schrieb:

Ein Stream von Audiodaten gehobener Qualität, soweit möglich in Realtime über IP und was das für Implikationen bzgl. Taktung aufwirft.

Wenn denn nun warum auch immer der Sender den Takt vorgibt, gibt es dafür grob gesagt eine ganz 'einfache' Lösung: der Drift wird erkannt und der Takt entsprechend angepasst. Als Beispiel könnte man hierzu die schon mal erwähnte Artikelserie über die Entwicklung eines USD-DAC (Burr Brown) für den isochronen Mode hernehmen, dort wird eine PLL verwendet.
Oder aber etwas mehr ontopic-'IP'-mässiges: Taktrückgewinnung IP / DVB - schönes Paper über verschiedene Anpassungsmöglichkeiten des Taktes

Und wieder mal wird klar, daß dies alles Dinge sind, die die Implementierung der Endgeräte betreffen und 'Kabel' (sofern sie innerhalb der Spec sind ) keinen Einfluß darauf haben ...

Hörschnecke (Beitrag #268) schrieb:

Eine erweiterte Deutung anhand dieser Richtungsumkehr könnte nun sein, daß die Samplerate auf Laptop1 etwas geringer, als auf Laptop2 ist. Dann wurde möglicherweise ein leergelaufener Buffer im ersten Versuch mit Nullen überbrückt, bis er wieder gefüllt war. Bei der Richtungsumkehr könnte der Buffer übergelaufen und sein Inhalt verworfen worden sein.

Man könnte auch mal lesen, dann müsste man nicht deuten ... #263

Da wird ein Nebenkriegsschauplatz nach dem anderen eröffnet aber die einzig relevante Frage wird nicht beantwortet:

Was kann ein High-End Lan Kabel besser als Standardware?

"....Was kann ein High-End Lan Kabel besser als Standardware?..."

Einfache Frage, einfache Antwort:
Schneller und einfacher den Gewinn steigern.
Für alles andere gibt es Nebelwerfer.
Also wenn das kein Grund ist???

@NochKeinHiFi,
es ist viel einfacher, man überträgt für Heimanwendungen, den Audio-Takt überhaupt nicht,
macht kein Echtzeit, und kommt mit TCP/IP alleine aus.
Im Sender wird einfach kein Audiotakt erzeugt!
Wo kein Audiotakt übertragen wird, kann er auch nicht jittern und muss auch nicht nachgeführt werden.
Der Verhinderung von Pufferüber- und Unterlauf ist im TCP/IP selber geregelt.

Es gibt an der Stelle absolut keine Probleme, mal abgesehen davon, dass durch Manchester-Codierung, die Bits sowieso alle richtig übertragen werden, selbst bei allerschlechtestem und stark gestörtem Kabel.

Plankton (Beitrag #273) schrieb:

Da wird ein Nebenkriegsschauplatz nach dem anderen eröffnet aber die einzig relevante Frage wird nicht beantwortet: Was kann ein High-End Lan Kabel besser als Standardware?

Doch - zwei Beiträge vor deinem - Antwort: nichts

bugatti66 (Beitrag #275) schrieb:

@NochKeinHiFi, es ist viel einfacher, man überträgt für Heimanwendungen, den Audio-Takt überhaupt nicht, macht kein Echtzeit, und kommt mit TCP/IP alleine aus.

Richtig, wenn man z:B. ein auf seinem NAS gespeicherten Track mit einem Player ausgibt, welcher einfach die Datei von NAS als Datei holt, hat man NULL - 0 - keine Probleme ....

Edith:
Aber 'leider' gibt es die 'anderen' Dinge eben auch (z.B. isochroner USB-Mode für Audio - kannte ich vor 4 Jahren auch noch nicht), aber dort gibt es ja auch Lösungen - und die Kabel können nix dafür ....

NochKeinHifi (Beitrag #271) schrieb:

... isochronen Mode ... PLL

Wir haben bei gewöhnlichen, paketorientierten Daten / IP erstmal keinen "isochronen Mode", wie z.B. bei S/PDIF im Audiobereich. Das verstehen die meisten hier nur nicht. Genausowenig, daß es einen Unterschied macht, eine WAV-Datei asynchron als ganze Datei über ein Netzwerk zu kopieren oder sie mit kurzer Latenz nahe Echtzeit zu streamen. Das naive Mantra Digital=Digital ist eben nicht auszurotten.

NochKeinHifi (Beitrag #276) schrieb:

Doch - zwei Beiträge vor deinem - Antwort: nichts :*

Das ist auch meine Erwartung

Es wäre nur schön mal etwas präzises von den Befürwortern der High-End Lan Kabel zu lesen. Da kommt leider rein gar nichts.

Immer sehr unterhaltsam

https://www.stereo.d...f/2008/12-08/069.pdf

Hörschnecke (Beitrag #278) schrieb:

NochKeinHifi (Beitrag #271) schrieb: ... isochronen Mode ... PLL Wir haben bei gewöhnlichen, paketorientierten Daten / IP erstmal keinen "isochronen Mode", wie z.B. bei S/PDIF im Audiobereich.

Dein 'Bastel'-Progrämmchen macht aber genau so etwas ähnliches daraus ... Sender gibt den Takt vor - Empfänger muss schauen, was er macht, macht aber nur das 'einfachste' (Daten auslassen/wiederholen...)
Da müsste es dann schon auf 1-Sample-Ebene mal was interpolieren/over/undersampeln über mehre Werte hinweg (macht es aber nicht, daher sage ich auch Bastelprogrämmchen, / Semesterarbeit ...)

Ausserdem hast du danach gefragt wie es richtig gelöst wird (Livestream, DVB..)....

Warum man sich sowas antut, verstehe ich auch nicht, da nicht notwendig ....

Hörschnecke (Beitrag #278) schrieb:

Genausowenig, daß es einen Unterschied macht, eine WAV-Datei asynchron als ganze Datei über ein Netzwerk zu kopieren oder sie mit kurzer Latenz nahe Echtzeit zu streamen. Das naive Mantra Digital=Digital ist eben nicht auszurotten.

Richtig, durch das Streamen kann man sich, wenn man es 'falsch' macht und/oder die falschen Tools verwendet nur Probleme einhandeln, weil dann eben 'bitidentisch' plötzlich nicht mehr gegeben sein muss - ist aber wie schon oft gesagt
a) nicht notwendig
b) kann man es 'richtig(er)' machen
c) ist das Sache von der Implementierung der Endpunkte
d) können da Kabel (sofern innerhalb der Spek) nichts daran ändern

Ob Audio-Streaming in hoher, garantierter Qualität eine Daseinsberechtigung hat oder nicht, maße ich mir nicht an. Von mir aus kann jeder auch wie früher seine CD zu Fuß zum Kumpel tragen und erst dort wieder abspielen.

Aber die hier anfangs von anderen vielfach vertrete, plärrige Anmaßung, daß digitales streaming per se keine Takt-Probleme habe/haben könne und Datenintegrität garantiert sei, teile ich eben nicht (und meine, es an meinem Experiment auch praktisch nochmal belegt zu haben). Das Problem asynchroner Taktung bei IP ist leider nicht auf einzelne Software-Umsetzungen beschränkt, sondern liegt tiefer. Antwort auf Lösungsansätze gab es zwischenzeitlich ja bereits von Jakob1863 mit dem Hinweis auf AVB (Audio Video Bridging) und dem Link eines anderen Users, der diese Grundlagen etwas vertieft: http://www.linux-magazin.de/Ausgaben/2013/11/AVB

Hörschnecke (Beitrag #283) schrieb:

Aber die hier anfangs von anderen vielfach vertrete, plärrige Anmaßung, daß digitales streaming per se keine Takt-Probleme habe/haben könne und Datenintegrität garantiert sei, teile ich eben nicht (und meine, es an meinem Experiment auch praktisch nochmal belegt zu haben).

das hatten wir schon vor 2 Seiten geklärt, daher ja auch immer die Aussage, was kann das arme Kabel dafür ...

Hörschnecke (Beitrag #283) schrieb:

Das Problem asynchroner Taktung bei IP ist leider nicht auf einzelne Software-Umsetzungen beschränkt, sondern liegt tiefer. Antwort auf Lösungsansätze gab es zwischenzeitlich ja bereits von Jakob1863 mit dem Hinweis auf AVB (Audio Video Bridging) und dem Link eines anderen Users, der diese Grundlagen etwas vertieft: http://www.linux-magazin.de/Ausgaben/2013/11/AVB

Richtig, sage ich ja auch nichts anderes:

NochKeinHifi (Beitrag #282) schrieb:

b) kann man es 'richtig(er)' machen c) ist das Sache von der Implementierung der Endpunkte

soooo - nun genug offtopic ....

Hörschnecke,

du hast völlig recht, wenn man es falsch macht, dann funktioniert es auch nicht richtig. Klingt komisch, ist aber logisch.

Kaum aber macht man es richtig, schon klappt es auch - selbst beim streaming.

Deswegen ist auch eine falsche Implementation von Streaming Software der Beweis für die Segensreiche Wirkung deines Super-Hi-End-Lan-Kabels, nicht wahr.

Die Stereo hat's vorgemacht: Cat5 klingt kühl und analytisch, erst bei Cat6 kommt der sonore Grundton zum tragen. Das muß man sich erstmal vorstellen!


Grüße

Hörschnecke (Beitrag #283) schrieb:

Aber die hier anfangs von anderen vielfach vertrete, plärrige Anmaßung, daß digitales streaming per se keine Takt-Probleme habe/haben könne und Datenintegrität garantiert sei,

Das ist ja auch Blödsinn. Es geht nicht nur um Files, sondern um Audiodaten und die reagieren bekanntermaßen sehr sensibel auf Zeitffehler.
Offenbar gibt es doch hörbare Klangunterschiede, wie man hier lesen kann. Hat denn mal Jemand wirklich einen Hörvergleich gemacht?

Jau, habe ich!

Ergebnis: Ich konnte keinen Unterschied hören.
DAS widerum bedeutet: Es gibt keinen Unterschied

@samusan,

Wie wäre es sich mal sich mit Digitaltechnik zu beschäftigen.
Audiodaten sind eines nämlich auch nur Bits und Bytes.

Ich müsste verdammt viel Vodka saufen bevor ich den Mist glaube der bei deinem Link so verbreitet wird.
Du solltest dir einfach vor Augen führen das dem Kabel scheiß egal ist welche Daten es überträgt, es weiß nicht ob Daten aus einer Worddatei, oder Audiodaten überträgt, Bitte verwechsel die Umwandlung von Bits und Byte in Tönen nicht mit der Übertragung von Bits und Bytes über eine Leitung.

"Champagne" wäre doch auch ein prickelnder Name für ein High End LAN-Kabel in der 1000 €/m Klasse.

Den betörend schönen Swing dieses Kabels würde der STEREO Böde doch ohne Wenn und Aber aalglatt raushoeren.

Spätestens dieser Thread hat gezeigt, dass man das OSI-Model mit einem Layer 8 erweitern muss. Der Layer 8 repräsentiert die User-Ebene.

Grundsätzlich kann man zwischen Problemorientierten und andererseits Lösungsorientierten Usern differenzieren, oder auch zwischen High-Endern oder Menschen mit gesundem Menschenverstand.
Der High-Ender, bzw. der Problemorientierte bevorzugt die Komponenten im OSI-Modell, die zumindest theoretisch ein Problem versprechen, das er dann mit Voodoo-Artikeln zu begegnen weiss, bzw begegnen möchte.

Der intelligente User ( ), also der Lösungsorientierte, analysiert seinen Anwendungsfall und wählt die Komponenten die bezogen auf seinen Anwendungsfall keine Probleme bereiten, weder in der Praxis noch in der Theorie.

Ich werde es wohl nie verstehen, warum man als HiFi-Kosument plötzlich in der Rolle der Musik-Produzenten schlüpfen möchte, die gezwungenermaßen bei Verwendung der Netzwerktechnologie sich über Realtime-Restriktionen Gedanken machen müssen. Aber selbst diese Profis sehen, auf die Praxis bezogen, nicht die Probleme, wie sie die Schlangenölverkäufer den Voodoo-Gläubigen herbeierklären möchten, auf dass sie dann ihre fadenscheinigen (Kabel)Produkte kaufen, die angeblich Probleme lösen sollen, die gar nicht da sind.

Wer mehr lesen möchte hier

PS. Wer von euch braucht fürs Audio-Streaming eine Realtime-Applikation?

Eisbär64 (Beitrag #288) schrieb:

@samusan, Wie wäre es sich mal sich mit Digitaltechnik zu beschäftigen. Audiodaten sind eines nämlich auch nur Bits und Bytes. Ich müsste verdammt viel Vodka saufen bevor ich den Mist glaube der bei deinem Link so verbreitet wird. Du solltest dir einfach vor Augen führen das dem Kabel scheiß egal ist welche Daten es überträgt, es weiß nicht ob Daten aus einer Worddatei, oder Audiodaten überträgt, Bitte verwechsel die Umwandlung von Bits und Byte in Tönen nicht mit der Übertragung von Bits und Bytes über eine Leitung.

Du verstehst es einfach nicht.
Der audiophile Mensch beschäftigt sich nicht mit "Daten" oder "Digitaltechnik" und "Audiodaten" sind auch nicht einfach "Daten". Der audiophile Mensch ist ein sensibles, feinnerviges, zu immenser Empfindsamkeit fähiges Wesen, eine Künstlerseele sui generis. So jemand hört keine Musikreproduktion aus toten Einsen und Nullen, er hört ... MUSIK! Und die kommt nicht einfach aus Daten, die irgendwie fehlerfrei von A nach B fließen, diese Audiodaten sind vielmehr genauso sensibel und zart wie der, der sie hört. So, wie du den audiophilen Menschen mit deinem rohen Techniker-Jargon verletzt, so verstörst du die empfindlichen Audiodaten durch das billige Baumarkt-LAN-Kabel, mag das CAT7 sein, soviel es will. Du kannst doch diese zarten Dätlein nicht durch billiges Kupfer jagen, was denkst du denn! Die haben doch schließlich auch ihren Stolz! Nein, nein, da muss es eben Silber sein, nur so kann sich die Klarheit der Musik wahrlich entfalten. Und mit deinem Versuch, Musik(!)daten mit einer Worddatei zu vergleichen, hast du dich ja wohl so was ins audiophile Abseits geschossen, wie es nur geht, schäm dich! Wo hat denn eine Worddatei "musikalischen Fluss", "tonale Feinnervigkeit" oder "stupendes Rhythmusgefühl"? Na bitte!

MaTel (Beitrag #243) schrieb:

<snip> 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.

Wo habe ich meine Behauptung "ins Gegenteil umgedeutet" ??

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.

Trotzdem kann man ab und zu mal den Überblick verlieren; du hattest offenbar nicht mitbekommen, dass es in Hörschneckes Anwendung um UDP-Ports (und Übertragung) ging und deshalb die Behauptung "Datenintegrität ist gesichert" schlicht falsch war.
Kann passieren, aber weshalb fällt es dir (und vielen deiner Glaubenskollegen, das kann man nach >10 Jahren Forumserfahrung sagen) so schwer, das einzugestehen?
Keine Angst, es fällt einem nicht der Himmel auf den Kopf und man muss danach auch nicht an LAN-Kabelklang glauben.

Mit den Scheinargumenten, ....

Scheinargumente sind z.B. "wegen Paketorientierung und Pufferung kann Jitter unmöglich zur Signaländerung führen" ; ich hatte dir einige Beispiele genannt, in denen durch einfache Messung an den Analogausgängen der betreffenden Geräte gezeigt werden konnte, dass "Jitter" sehr wohl zur Signaländerung führen kann (Paketorientierung und Pufferung zum Trotz).
Wie so oft keine Reaktion, stattdessen Tiraden über angebliche Scheinargumente Anderer; das ist nicht sinnvoll.

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.

ME sind daran mindestens zu gleichen Teilen Forumsteilnehmer schuld, die sich gemeinschaftlich auf die Schulter klopfen, und sich auf der Grundlage technisch unhaltbarer Argumentation über Hörer "beömmeln" .

bugatti66 (Beitrag #249) schrieb:

<snip> 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?

"Anhänger" sowie die inbrünstige "Glaubensprosa" des verlinkten Beitrags sind halt mehr etwas für deine Überzeugungsrichtung.
Mich interessiert mehr die technisch richtige Darstellung insbesondere dann, wenn man lautstark behauptet, dies sei das Forum, in welchem auf physikalisch-wissenschaftlicher Grundlage argumentiert würde.

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!

Seufz, bezieht sich auf den sog. "Interface-jitter" und wie bei jeder anderen derartigen Schnittstelle findest du selbstverständlich auch in den IEEE Ethernet Standards die Jittergrenzwerte, die einzuhalten sind resp. die noch zu fehlerfreier Verarbeitung innerhalb des Empfängers führen müssen.
Wie auch schon bei den ähnlich codierten Signalen der S/PDIF bzw. AES-EBU-Schnittstelle.

Das die Checksumme der UDP-Pakete nur dann hilft, wenn das Paket auch wirklich angekommen ist - in einer Echtzeit-Audiowiedergabe sollte es darüberhinaus auch noch _rechtzeitig_ angekommen sein, ist vielleicht ein kleiner Stolperstein, mhm?
MWn bestand darüberhinaus auch kein Zwang, die Checksumme zu verwenden. (Manchester-Coding ists vermutlich heute auch nicht mehr, aber sicher eine modernere Variante, die die Taktwiederherstellung begünstigt)

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

Ja, in welcher Hinsicht?
Das Thema an der Stelle (deshalb auch zitiert), war, das Jitter wegen der Paketorientierung und wegen der Puffer keinen Einfluss haben kann und die verlinkte Publikation zur IEEE1394 zeigt das Gegenteil.

Pigpreast (Beitrag #244) schrieb:

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

Keine Ahnung.
Wenn ich nochmals an die Empfehlung erinnern darf, dass man erst aussagekräftige Messungen und ebensolche Hörversuche machen sollt.....

hifi_angel (Beitrag #290) schrieb:

Spätestens dieser Thread hat gezeigt, dass man das OSI-Model mit einem Layer 8 erweitern muss. Der Layer 8 repräsentiert die User-Ebene.

Ich dachte das wurde bereits "intern" herumgereicht ...

Ausbildung Fachinformatiker für Systemintegration 2002 - 2 Woche:
Osi Referenzmodell - Habt ihr alle Gelernt? - wer kennt Schicht Acht? Da entstehen die meisten Probleme ...

Ok, war als Scherz des Dozenten gemeint, aber das er recht hat, wusste jeder - spätestens nach dem ersten "First Level Support" - Einsatz... ^^

Hallo,

also: Lösungen anbieten für die es gar keine Probleme gibt - aber groß rumtönen wie toll die Lösungen funktionieren.

Jo, so funzt High-End-Marketing.

Um Super-Ingo zu zitieren "Hören Sie es, hören Sie es? Das muss man doch hören!"

Is klar... is klar...

Peter

Jakob1863 (Beitrag #294) schrieb:

Keine Ahnung.

Hab mich gerade "beömmelt"

Gruß jandus

Was ist denn an Jakobs Richtigstellungenn falsch? Es sind einige hier wohl etwas pikiert da man ihnen ihr Halbwissen unter die Nase reibt.

Haben denn nun LAN-Kabel keinerlei EInfluss auf den Klang? Bisher wird das wohl nur geglaubt.

samusan (Beitrag #299) schrieb:

Haben denn nun LAN-Kabel keinerlei EInfluss auf den Klang? Bisher wird das wohl nur geglaubt.

Dann leg mal los und Beweise leicht reproduzierbar, dass die teuren Lan Kabel den Aufpreis Wert sind und mehr können als Standardware.
Sollte doch ein leichtes für Dich sein aber ich vermute, dass Du hast es auch nicht drauf hast.

Hallo,

Schön, hat der Entwickler, Produzent und Vertreiber doch mal einen Fanclub, oder soll ich sagen Jünger?
Wenn es technische Probleme bei der Datenübertragung gibt - egal aus welchem Grund - kann kein Kabel der Welt diese Probleme lösen. Wer so einen Mist glaubt glaubt auch das Zitronenfalter Südfrüchtekaltverformer sind.

Aber Jünger sind halt so...

Peter

Jakob1863 (Beitrag #260) schrieb:

Ich habe den Zusammenhang so beschrieben, weil innerhalb der 802-Gruppe die Ziele, die mit AVB verfolgt/erreicht werden sollten, genau so beschrieben wurden: Two key AVB requirements -Guaranteed QoS •Resource reservation and admission control for media streams •Meet jitter, wander, time synchronization and latency requirements of applications •Along with end-to-end requirements, must consider reference model(s) to determine allocation to AVB network (Quelle: den Hollander, Garner, Ryu - Samsung - ; Präsentation anläßlich des "The 4th International Telecoms Synchronization Forum 2006" )

Gut, jetzt weiß ich, warum Du schriebst, was Du schriebst. (Schrieb ich nicht von vornherein, dass ich Zweifel ob der von mir vermuteten Plumpheit hegte?)

Aber sei's drum. So richtig verstanden habe ich immer noch nicht:

Jakob1863 (Beitrag #294) schrieb:

Pigpreast (Beitrag #244) schrieb: Ja, wat is denn nu mit den audiophilen LAN- oder SATA-Kabeln? Wie verbessern die denn nun die Klangqualität? Keine Ahnung.

Aber darum geht es hier in diesem Thread doch und darum ging es mir die ganze Zeit. Ich stellte mein Verständnis der Bedeutung des Kabels bildhaft als Spediteur-Fuhrpark dar und bat (nicht nur Dich) mehrfach darum, man möge mir mein Missverständnis bzw. die Unzulänglichkeit meines Modells erklären. Und gut 50 Beiträge später lautet die Antwort: "Keine Ahnung"?

Wenn ich nochmals an die Empfehlung erinnern darf, dass man erst aussagekräftige Messungen und ebensolche Hörversuche machen sollt.....

Verstehe ich nicht. Die entwickeln ein Kabel, preisen es als "audiophil" an, aber es gibt keine Idee, wieso es das sein soll? Und es soll durch Messungen und Hörversuche getestet werden, ob es ein Versprechen hält, von denen man keinen blassen Schimmer hat, wieso es das überhaupt halten sollte?

Pigpreast (Beitrag #302) schrieb:

Verstehe ich nicht. Die entwickeln ein Kabel, preisen es als "audiophil" an, aber es gibt keine Idee, wieso es das sein soll? Und es soll durch Messungen und Hörversuche getestet werden, ob es ein Versprechen hält, von denen man keinen blassen Schimmer hat, wieso es das überhaupt halten sollte? :?

Du schreibst es, als sei es etwas ungewöhnliches im Hi-End-Geschäft...

Grüße