Nachdem ich mich in den letzten Monaten sehr ausführlich mit dem digitalen Medium als Musikquelle beschäftigte ergeben sich einige Aspekte, auf die ich so nicht vorbereitet war: Ein klanglich grosser Einfluss der Peripherie auf den Klang bei Einsatz von Netstreamer Technologie als Quellgerät.
Aktuell verwende ich als Abspielgerät den Linn Akurate G-ADS0 – der läuft via symmetrischer Verbinder an eine Linn Klimax Kontrol und die treibt ebenfalls symmetrisch eine Linn A350.
Nun aber zum Eigentlichen:
Da mein NAS (QNAP T102) mit Twonky doch eine gewisse Geräuschentwicklung hat musste er in den Nebenraum weichen. Der Verbindung zum ADS geschieht über 2 Fritz Router via 300Mbit Wireless, wovon einer, der den ADS mit Daten füttert als Bridge konfiguriert wurde: Funktioniert alles einwandfrei:
Und jetzt wird es interessant:
Klanglich positiv wirkt sich aus, wenn die Verbindung nicht via Wireless läuft sondern via 7 meter Ethernetkabel (mit nur 100Mbit !) – noch einen Schritt nach vorne komme ich wenn ich den NAS direkt an die Fritzbox klemme und somit NAS und ADS direkt am gleichen Router hängen ohne die Bridge dazwischen mit jeweils 50 cm Lan Kabel. (das UnPn Protokoll ist an sich TCP basierend - und damit verbindungsorientiert und mein Wifi wird auch exklusiv nur von den beiden Fritzboxen verwendet, da ist kein anderer Bandbreitenkiller drin)
Weiterhin:Unterschiedliche Ethernetkabel „klingen“ sehr unterschiedlich, das hat nicht unbedingt etwas mit der Länge oder der Cat: 5,6 oder 7 zu tun. Sondern es liegt eher an den Herstellern. Die Unterschiede offenbaren sich zu allererst in der Tonhärte – also mit welcher Wucht bspw. Ein Klavier oder Schlagzeugeinsatz kommt, aber auch in der gesamten Bassgriffigkeit. Auch die Struktur und Ordnung bei klassischer Musik nimmt zu.
Einen weiterer grosser Schritt in diese Richtung ist der Einsatz eines 1Gbit Switches von Digitus (Ein Netgear Switch bringt keine Verbessung gegenüber dem Fritz Router) – Der Digitus Switch minimiert auch den Kabeleinfluss etwas.
Der absolute Schritt nach vorne ist aber die Verwendung von SSD Platten in einem NAS gegenüber den normalen Festplatten (hatte hier ein NAS mit Buffalo SSD im Vergleich zu meinem Qnap – aber die Bestellung eines SSD NAS ist schon geplant, der Sprung ist einfach 500 Euro wert.)
An sich bin ich solche Einflussketten eher bei Plattenspielern gewohnt (der Parameterraum ist hier praktisch beliebig und führt von passablen bis hervorragenden Ergebnissen bei gleicher Laufwerk / Arm Ausstattung – abhängig von mechanisch optimaler Aufstellung, Stromversorgung, Sorgfalt der Justierung, etc. etc)
Es eröffnet sich bei der Verwendung von digitalen Medien anscheinend ein ebensolch schwer beherschbarer Parameterraum, da ich aufgrund der Daten von Kabel, Router, Switches, NAS Festplatten keinerlei Kriterium finden kann, an dem ich die klanglichen Auswirkungen festmachen koennte – Trial and Error – dachte an sich, das waere bei digitaler Streamertechnik passe.
Mir ist bewusst, dass ich mit diesem Thread so etwas wie die Büchse der Pandora öffnen werde, da einige Forenmitglieder diese Klangauswirkungen schlicht negieren oder bei sich selbst bisher nicht feststellen können. Ich kann nur anführen, dass ich auf solch grosse Unterschiede nicht gefasst war und selbst sehr erstaunt war und bin, wie gross der Einfluss der Peripherie auf den Klang meines ADS ist.
Mich interessieren hier Eure Erfahrungen gerade im Zuspiel mit Netzplayer als Quelle.
Rainer
Klangeinfluss durch Netzperipherie bei Streamertechnologie
Eigentlich rätselhaft denn der Abspieler sollte doch einen ausreichend großen Zwischenspeicher und eine nicht auf Paketverzögerungen reagierende Elekrtronik haben. Wenn ja dann ist das Gerät nicht optimal, was ich bei Linn eigentlich nicht unterstellen würde. Die geschilderten Symptome lassen auf Zeitfehler schließen, gerade die müsste ein guter Netzwerkspieler lässig und ohne Klangrückwirkung im Pufferspeicher auffangen, genau das ist das Schlüsselfeature eines solchen Gerätes. Vermutlich werden auch Störströme übers Ethernet Kabel, gerade bei Switches und auch in der Fritzbox passiert im Gehäuse so einiges hochfrequentes . Das Empfangsgerät sollte von diesen eigentlich nicht beeinflussbar sein, in Wirklichkeit aber irgendwie doch.
BvK
BvK
Hallo Rainer,Funky hat geschrieben: Mich interessieren hier Eure Erfahrungen gerade im Zuspiel mit Netzplayer als Quelle.
geprüft habe ich bisher nicht, inwieweit sich die Art und Weise der Netzwerkverbindung klanglich auswirkt. Verständlich finde ich, das WLAN bei Verbindungsproblemen hörbar schlechter sein kann und ansonsten kann es eine Rolle spielen, was du alles so über Dein Netzwerk jagst, während Du Musik hörst. Mein SSD NAS steht direkt neben dem Majik DS und ist mit diesem über einen eigenen Switch verbunden.
Ein Tip: Als SSD NAS verwende ich ein RipNAS Solid. Der sieht schick aus wie ein Hifi-Gerät. Da war eine schon recht gut bedämpfte 500 GB Platte drin. Da man diese dennoch hört, habe ich sie gegen eine 600 GB Intel 320 SSD ausgetauscht. Das ist nicht die schnellste SSD - aber für die Wiedergabe absolut ausreichend und vor allem mit geringem Stromverbrauch. Und man hört absolut nichts!!
Es gibt da jetzt eine Neuauflage mit WHS 2011, Asset uPnP R4 und dbpoweramp 14.2. Die beiden letzteren habe ich einfach selbst eingespielt ...
Viele Grüße
Georg
PS: Nett ist auch, dass das recht gute DVD-Laufwerk eine Schublade besitzt. Bei Slot-In Laufwerken habe ich mir des öfteren mal CD's durch Unachtsamkeit verkratzt. Und das Rippen ist schon herrlich bequem damit.
Hallo Georg,
das ist ein guter Tip, vor allem, dass dann der SSD NAS direkt neben dem Streamer stehen kann, gekoppelt via Switch. Was mich eben wundert, dass , wie BVK zurecht meint, so starke Auswirkungen hinsichtlich der Peripherie gar nicht geben sollte, aufgrund der Pufferung und eigenen Taktaufbereitung innerhalb des Streamers. Ein Monitoring der Wireless Strecke zeigt auch, dass ich keinerlei Transmission Probleme habe - und doch klingt es via Kabel einfach eine Klasse besser, von der Einschleifung eines Digi Swichtes ganz zu schweigen (und warum "klingt" der netgear richtig lasch gegen den Digitus ??) - Tja, da gibt es noch viele Fragen zwischen 0 und 1, die nicht einfach zu beantworten sind.
Werde mir mal den RipNAS Solid genauers anschauen.
Rainer
das ist ein guter Tip, vor allem, dass dann der SSD NAS direkt neben dem Streamer stehen kann, gekoppelt via Switch. Was mich eben wundert, dass , wie BVK zurecht meint, so starke Auswirkungen hinsichtlich der Peripherie gar nicht geben sollte, aufgrund der Pufferung und eigenen Taktaufbereitung innerhalb des Streamers. Ein Monitoring der Wireless Strecke zeigt auch, dass ich keinerlei Transmission Probleme habe - und doch klingt es via Kabel einfach eine Klasse besser, von der Einschleifung eines Digi Swichtes ganz zu schweigen (und warum "klingt" der netgear richtig lasch gegen den Digitus ??) - Tja, da gibt es noch viele Fragen zwischen 0 und 1, die nicht einfach zu beantworten sind.
Werde mir mal den RipNAS Solid genauers anschauen.
Rainer
Hallo Rainer,
ich habe einige CAT Kabel durchprobiert, bei mir spielt das
http://www.sommercable.com/excelsior/1/index.html
interessant finde ich, dass man auch die Signalrichtung der CAT Kabel raushoeren kann...,
einfach mal drehen!
Einen sehr grossen Einfluss auf den Klang hat bei mir auch die Stromversorgung von Router und NAS, habe hier mit grossem Erfolg Trenntrafos und gute Netzkabel im Einsatz.
netten Gruss
Juergen
ich habe einige CAT Kabel durchprobiert, bei mir spielt das
http://www.sommercable.com/excelsior/1/index.html
interessant finde ich, dass man auch die Signalrichtung der CAT Kabel raushoeren kann...,
einfach mal drehen!
Einen sehr grossen Einfluss auf den Klang hat bei mir auch die Stromversorgung von Router und NAS, habe hier mit grossem Erfolg Trenntrafos und gute Netzkabel im Einsatz.
netten Gruss
Juergen
Wenn man das so liest, bekommt man "Angst", tun sich doch hier jede Menge Baustellen auf.
Da ich vor der Einrichtung eines neuen Hörraumes stehe und diesen natürlich per Cat7 Install-kabel anbinden möchte, kommen mir Zweifel. Ist eine direkte Anbindung beispielsweise per esata die bessere Wahl? Bin gespannt was hier noch für Erfahrungswerte gepostet werden.
Peter
Da ich vor der Einrichtung eines neuen Hörraumes stehe und diesen natürlich per Cat7 Install-kabel anbinden möchte, kommen mir Zweifel. Ist eine direkte Anbindung beispielsweise per esata die bessere Wahl? Bin gespannt was hier noch für Erfahrungswerte gepostet werden.
Peter
Hi,
CAT 7 ist nicht verkehrt.
Du kannst ja am Geraet selbst ein anderes Kabel nehmen mit einer "anderen" Schirmung.
Habe ich hier im ganzen Haus (mittlerweile an die 70 Patchungen)
Btw. ich hoere keine UNterschiede, obwohl ich nicht glaube dass Cisco besonders audiophile ausgelegt ist.
Ich vermute ja immer noch ein Stoersignal, welches weitergeleitet wird. Hatte ich auch mal als ich ein CAT6 Kabel an einen Player angeschlossen habe, da hattes es auf einmal gebrummt.. dabei dachte ich immer da wird per default getrennt(war ein Netgear Gigbit Switch glaube ich)... naja.
Habe sowas hier in der neuen Installation nie mehr gehabt.
Gruss
Thomas
CAT 7 ist nicht verkehrt.
Du kannst ja am Geraet selbst ein anderes Kabel nehmen mit einer "anderen" Schirmung.
Habe ich hier im ganzen Haus (mittlerweile an die 70 Patchungen)
Btw. ich hoere keine UNterschiede, obwohl ich nicht glaube dass Cisco besonders audiophile ausgelegt ist.
Ich vermute ja immer noch ein Stoersignal, welches weitergeleitet wird. Hatte ich auch mal als ich ein CAT6 Kabel an einen Player angeschlossen habe, da hattes es auf einmal gebrummt.. dabei dachte ich immer da wird per default getrennt(war ein Netgear Gigbit Switch glaube ich)... naja.
Habe sowas hier in der neuen Installation nie mehr gehabt.
Gruss
Thomas
Moin zusammen,
es gilt fest zu halten, dass alle Cat7 Definitionen für Ethernet Kabel durch die nomalen RJ45 Stecker hinsichtlich der verlangten Übertragungsnorm (bis 600Mhz) nicht umsetzbar ist. Es gibt fuer die Einhaltung der Norm Cat7 eigene Steckertypen (siehe auch Wikipedia) , die sich bisher (aufgrund des RJ45 Verbreitungsgrades) nicht durchsetzen werden in der Fläche. Schon bei Cat6 müssen alle 8 Kabel auf aufgelegt und verwendet werden und das bringt mich eben zu der Thematik - unterschiedlicher "Kabelklang". Je nach Router oder Switch und dessen Alter, kann es einfach sein, dass mit einem älteren Cat5 mit 4 aufglegten Adern die gut verdrillt und geschirmt sind mehr anzufangen ist als mit Cat6 oder vermeintlicher Cat7 mit deren 8 aufgelegten Adern - die von älteren Geräten mit 100 Mbit gar nicht genutzt werden (Insofern bin auch auch bei den von Jürgen empfohlenen "Cat7 Ecselsior Kabel, etwas reserviert)
Meine Erfahrung zeigt an meiner Fritzbox (Baujahr 2007) und Digitus Switch (2011), dass mein 6 jahre altes Cat 5 (einfach vom Klangeindruck kraftvoller zu Geltung kommt, als ein Cat 6 neuester Bauart, bei gleicher Leitungslänge 7 m).
Also muss man genau wissen welche Geräte (welche Norm dann auch erfüllen) mit welchem Kabeltyp optimalerweise verbunden werden. Das macht es nicht gerade einfach so etwas wie ein optimale Kombination zu finden.
Ich hatte gestern abend auch eine Diskussion mit Jungs aus der Netztechnik hinsichtlich des Klangunterschiedes bei eingeschleiftem Switch zwischen NAS , Router und Netplayer - hier koennte das Thema Latency über unterschiedliche Puffergroessen eine Rolle spielen. Grössere Puffer im Ausgangsbereich des Senders fluten den ggf. kleineren Eingangspuffer des Netstreamers - an sich hangelt sich ja TCP über die Fenstergroesse immer höher hinsichtlich der Packetgroesse. Ein grosser Puffer beim Datenlieferant erzeugt aber eine grosse Latency genau dann, wenn der ev. kleinere Eingangspuffer auf Eingangseite volläuft - die Rückmeldung für congestion dauert aufgrund des grossen Puffers des Sender einfach länger (der Puffer wird erst mal geleert, bevor die Message der Congestion ankommt und die Fenstergroesse minimiert wird) - die Latency nimmt somit gegenüber kleinen Puffergroessen zu, und bei Echtzeitdaten ist Latency das primäre Thema - soweit mal zumindest ein paar theoretische Überlegungen warum zwischen Router und Netplayer eingeschleifte Switche den Klang substanziell verändern können.
Rainer
es gilt fest zu halten, dass alle Cat7 Definitionen für Ethernet Kabel durch die nomalen RJ45 Stecker hinsichtlich der verlangten Übertragungsnorm (bis 600Mhz) nicht umsetzbar ist. Es gibt fuer die Einhaltung der Norm Cat7 eigene Steckertypen (siehe auch Wikipedia) , die sich bisher (aufgrund des RJ45 Verbreitungsgrades) nicht durchsetzen werden in der Fläche. Schon bei Cat6 müssen alle 8 Kabel auf aufgelegt und verwendet werden und das bringt mich eben zu der Thematik - unterschiedlicher "Kabelklang". Je nach Router oder Switch und dessen Alter, kann es einfach sein, dass mit einem älteren Cat5 mit 4 aufglegten Adern die gut verdrillt und geschirmt sind mehr anzufangen ist als mit Cat6 oder vermeintlicher Cat7 mit deren 8 aufgelegten Adern - die von älteren Geräten mit 100 Mbit gar nicht genutzt werden (Insofern bin auch auch bei den von Jürgen empfohlenen "Cat7 Ecselsior Kabel, etwas reserviert)
Meine Erfahrung zeigt an meiner Fritzbox (Baujahr 2007) und Digitus Switch (2011), dass mein 6 jahre altes Cat 5 (einfach vom Klangeindruck kraftvoller zu Geltung kommt, als ein Cat 6 neuester Bauart, bei gleicher Leitungslänge 7 m).
Also muss man genau wissen welche Geräte (welche Norm dann auch erfüllen) mit welchem Kabeltyp optimalerweise verbunden werden. Das macht es nicht gerade einfach so etwas wie ein optimale Kombination zu finden.
Ich hatte gestern abend auch eine Diskussion mit Jungs aus der Netztechnik hinsichtlich des Klangunterschiedes bei eingeschleiftem Switch zwischen NAS , Router und Netplayer - hier koennte das Thema Latency über unterschiedliche Puffergroessen eine Rolle spielen. Grössere Puffer im Ausgangsbereich des Senders fluten den ggf. kleineren Eingangspuffer des Netstreamers - an sich hangelt sich ja TCP über die Fenstergroesse immer höher hinsichtlich der Packetgroesse. Ein grosser Puffer beim Datenlieferant erzeugt aber eine grosse Latency genau dann, wenn der ev. kleinere Eingangspuffer auf Eingangseite volläuft - die Rückmeldung für congestion dauert aufgrund des grossen Puffers des Sender einfach länger (der Puffer wird erst mal geleert, bevor die Message der Congestion ankommt und die Fenstergroesse minimiert wird) - die Latency nimmt somit gegenüber kleinen Puffergroessen zu, und bei Echtzeitdaten ist Latency das primäre Thema - soweit mal zumindest ein paar theoretische Überlegungen warum zwischen Router und Netplayer eingeschleifte Switche den Klang substanziell verändern können.
Rainer
Rainer,Funky hat geschrieben:es gilt fest zu halten, dass alle Cat7 Definitionen für Ethernet Kabel durch die nomalen RJ45 Stecker hinsichtlich der verlangten Übertragungsnorm (bis 600Mhz) nicht umsetzbar ist. Es gibt fuer die Einhaltung der Norm Cat7 eigene Steckertypen (siehe auch Wikipedia)
voellig ok, aber es macht immer noch Sinn bei Verlegungen ein CAT7 Kabel zu nutzen. Schirmung, sowie Zukunftssicherheit sollten bei Unterputz-Verlegung (davon rede ich) mit eine Rolle spielen. Ob Du dann Deine 4 oder 8 Adern nutzt, wenn Du dann aus der Dose zum Geraet gehst bleibt Dir ja ueberlassen. OK, man koennte ueber Glasfaser mit konvertern nachdenken ... Hatte ich auch schon mal ueberlegt ... aber zum Schluss geht es eh ueber Kupfer ins Geraet.
Ich kann mich Ulli nur anschliessen und tippe immer noch auf Stoerungen, die "untechnisch" gesprochen das Geraet beinflussen, unabhaengig vom Datentransport, der ueber die Leitung geht....
Ich komme aus der IT, von daher weiss ich so etwa wie die einzelnen Datenstroeme funktionieren... vielleicht faellt es mir deshalb so schwer, mich auf eine Diskussion SSD/klassische Disk oder Router einzulassen, die das Klangbild veraendern... aus der IT-Sicht wohlgemerkt. Wenn da doch noch Stoerstroeme rueberkommen muesste es sich doch mit einem Trennglied (galvanische Trennung) eliminieren lassen oder?(Wie gesagt, ich dachte immer, dass dies Standard in einem RJ45 Ethernet-Port sei.)
Mal sehen, welche Erkenntnisse sich hier noch ergeben, ich versuche gerne weiter meine Erfahrungen mit einzubringen, wenn es der Sache dient.
Gruesse
Thomas
Hallo Thomas,
da geht es Dir wir mir, ich bin Physiker (und auch in der IT - wenn inzwischen auch im Sales) - aber ich hatte in meiner Vergangenheit ziemlich viel Stippen und Patchkabel gezogen, bzw. Hochgeschwindikeitsmodems via Lichtleiter verlegt - die Daten kamen an oder nicht, da gab es nichts daran zu deuteln. Wenn Fehler vorhanden waren - ein Fluke dran und man wusste ob auf Layer1 oder 2 der Hund begraben lag. Insofern bin ich eben auch überrrascht, dass es überhaupt zu hörbaren Unterschieden kommt. Laut meiner Ausbildung - duerfte es das alles in dieser Form nicht geben. Gerade weil TCP auch noch ein verbindungorientieres Protokoll ist - da darf nichts verloren gehen, auch wenn das ein oder andere Bit umkippen sollte, ein retransmit + Puffer, und es dürfte nichts anbrennen.
Soweit leider nur die Theorie, mein Ohr sagt da einfach was anderes (das meiner Frau auch, und die hat mit Technik gar nichts am Hut, gibt nur den Daumen rauf oder runter
Was wohl Sinn macht: Hochwertiger Router der definitiv 1 Gbit verarbeitet (da ist meine Fritzbox wohl nicht State of the Art aus audiophiler Sicht) Cat6 Kabel, so kurz wie möglich, Switch dazwischen (und alles stromkreismässig vom Rest der Anlage getrennt und dann - aehmm, ja doch eine SSD NAS Lösung -
Als Physiker ist da natuerlich meine Neugier geweckt, immer dann, wenn es anders verläuft als die Theorie vorhersagt, wird es interessant - denn dann betritt man Neuland. Ich habe nur leider keinerlei Messgeräte Park um den Dingen physikalisch auf den Grund zu gehen. (Latency, Pufferauswirkung, Jittergenerierung, etc.) Werde mich mal an Gert Volk wenden, er ist ja schon ein Digitalgenie -
Wenn ich denke, dass optimale Setting gefunden zu haben (mit vertretbaren pekuniärem Aufwand) dann werde ich das hier gerne posten - aktuell nutze ich sehr sehr gerne Euren Input um mich diesem Optium anzunähern. Danke dafür.
Rainer
da geht es Dir wir mir, ich bin Physiker (und auch in der IT - wenn inzwischen auch im Sales) - aber ich hatte in meiner Vergangenheit ziemlich viel Stippen und Patchkabel gezogen, bzw. Hochgeschwindikeitsmodems via Lichtleiter verlegt - die Daten kamen an oder nicht, da gab es nichts daran zu deuteln. Wenn Fehler vorhanden waren - ein Fluke dran und man wusste ob auf Layer1 oder 2 der Hund begraben lag. Insofern bin ich eben auch überrrascht, dass es überhaupt zu hörbaren Unterschieden kommt. Laut meiner Ausbildung - duerfte es das alles in dieser Form nicht geben. Gerade weil TCP auch noch ein verbindungorientieres Protokoll ist - da darf nichts verloren gehen, auch wenn das ein oder andere Bit umkippen sollte, ein retransmit + Puffer, und es dürfte nichts anbrennen.
Soweit leider nur die Theorie, mein Ohr sagt da einfach was anderes (das meiner Frau auch, und die hat mit Technik gar nichts am Hut, gibt nur den Daumen rauf oder runter
Was wohl Sinn macht: Hochwertiger Router der definitiv 1 Gbit verarbeitet (da ist meine Fritzbox wohl nicht State of the Art
aus audiophiler Sicht) Cat6 Kabel, so kurz wie möglich, Switch dazwischen (und alles stromkreismässig vom Rest der Anlage getrennt und dann - aehmm, ja doch eine SSD NAS Lösung - Als Physiker ist da natuerlich meine Neugier geweckt, immer dann, wenn es anders verläuft als die Theorie vorhersagt, wird es interessant - denn dann betritt man Neuland. Ich habe nur leider keinerlei Messgeräte Park um den Dingen physikalisch auf den Grund zu gehen. (Latency, Pufferauswirkung, Jittergenerierung, etc.) Werde mich mal an Gert Volk wenden, er ist ja schon ein Digitalgenie -
Wenn ich denke, dass optimale Setting gefunden zu haben (mit vertretbaren pekuniärem Aufwand) dann werde ich das hier gerne posten - aktuell nutze ich sehr sehr gerne Euren Input um mich diesem Optium anzunähern. Danke dafür.
Rainer
Uli,
noch eine Anmerkung zum Thema Puffer, - die Puffer werden bei Routern / Switches genutzt, damit es nicht zu DropOut / Latency Effekten kommt. Sollte bspw. Anfragen von 4 Clients gleichzeitig auf einen Server erfolgen (sprich auf einem Switch senden 4 Ports gleichzeitig auf einen Port )- das kann zu Congestions führen, also werden die Datenpackete kurz gepuffert, und dann wenn keine Congestions per auf dem Serverport liegen, diese rausgesandt - grosse Puffer hier also sinnvoll. Wenn ich aber nur einen Client und einen Server habe, und der Server mir zu schnell die Daten liefert, der Client damit nicht klarkommt, dann muss der Client via TCP ein Rücksignal geben, he, mach mal langsamer, ich muss packete wegschmeisen, - das rücksignal kommt aber erst tragen wenn die im Puffer verbliebenen Daten praktisch mit der hohen (sprich grossen MTU Size von bis zu 1500 byte) schon gesendet wurden - die werden dann vom Client also auch noch weggeworfen - - ein grosser puffer induziert also eine grosse latency - und da koennte wirklich ein problem entstehen - nicht wegen DropOuts, sondern interner Rechenoperationen auf Client Seite - soweit die Theorie.
Jau, aber wir wissen, alle Theorie ist grau - mein Switch scheint das auf jeden Fall irgendwie so hinzubekommen, dass der Streamer sich nicht so anstrengen muss - und das mit wesentlich besseren , weil strukturiertem Klang, belohnt (aber nur der Digitus, nicht der Netgear, der hat keinerlei Effekt)
Rainer
noch eine Anmerkung zum Thema Puffer, - die Puffer werden bei Routern / Switches genutzt, damit es nicht zu DropOut / Latency Effekten kommt. Sollte bspw. Anfragen von 4 Clients gleichzeitig auf einen Server erfolgen (sprich auf einem Switch senden 4 Ports gleichzeitig auf einen Port )- das kann zu Congestions führen, also werden die Datenpackete kurz gepuffert, und dann wenn keine Congestions per auf dem Serverport liegen, diese rausgesandt - grosse Puffer hier also sinnvoll. Wenn ich aber nur einen Client und einen Server habe, und der Server mir zu schnell die Daten liefert, der Client damit nicht klarkommt, dann muss der Client via TCP ein Rücksignal geben, he, mach mal langsamer, ich muss packete wegschmeisen, - das rücksignal kommt aber erst tragen wenn die im Puffer verbliebenen Daten praktisch mit der hohen (sprich grossen MTU Size von bis zu 1500 byte) schon gesendet wurden - die werden dann vom Client also auch noch weggeworfen - - ein grosser puffer induziert also eine grosse latency - und da koennte wirklich ein problem entstehen - nicht wegen DropOuts, sondern interner Rechenoperationen auf Client Seite - soweit die Theorie.
Jau, aber wir wissen, alle Theorie ist grau - mein Switch scheint das auf jeden Fall irgendwie so hinzubekommen, dass der Streamer sich nicht so anstrengen muss - und das mit wesentlich besseren , weil strukturiertem Klang, belohnt (aber nur der Digitus, nicht der Netgear, der hat keinerlei Effekt
)Rainer
Hi Rainer,
(Sales... ja, ihr macht mir immer das Leben schwer mit Dingen die es noch nicht gibt)
fein(koennte konstruktiv werden), nur bitte auch nicht vergessen, von welchen Datenraten wir hier reden. Das sind Peanuts, meiner Meinung nach. Gerade wenn wir 44.1 vergleichen (500k maximum). Latency ok, aber hier geht es meiner Meinung nach immer noch nicht um RT Daten die abgearbeitet werden muessen(also in dem Prozess des Datenaustausches und da ist das Kabel welches man im unterschied hoert), sondern um Daten die ankommen und verworfen werden koennen.
Kurzes Kabel ok, aber nicht der Latenz wegen.
Diese CPU Thematik macht mir da echt zu schaffen, mehr Umdrehungen mehr Strom dadurch mehr Uebersprechungen?.... Hach da halte ich mich mal raus, ich habe schon immer beim Stealth Player mitgelesen, aber mir fehlt da irgendwie der Dreh mit einem System zu arbeiten, welches OOS ist, und eh seine Problemchen mit dem Threaden hat/hatte. Warum nicht so eine SW auf ein vernuenftiges System aufsetzen und dann mal diese Auslastungsthematik angehen?
Aller Theorie nach koennte man ja nur die Sache mit einem System in Angriff nehmen, auf welchem man Zugriff hat, um genau diese Punkte messen(jaja, wer misst misst mist oder so aehnlich) zu koennen.
Es muss ja nicht alles superaudiophil sein, sondern wir wollen ja die Unterschiede in einen Kausalen Zusammenhang stellen koennen(wenn es zu schlecht ist, bekommt man evtl nichts mit)
Ok bevor jetzt hier jemand mit XP vorprescht..
Ich denke da eher an ein/zwei Linux Systeme, dafuer gibt es meiner Meinung nach mehr Tools zum analysieren.
Dann ein Playersystem(Client) und einen Server.
CPU/mem/IOPS/Latency etc. ueber nmon z.b.
Definition der Testreihen, vor allendingen muss man da ja nun was hoeren
tcpdump zum snoopen, koennte man natuerlich auf einen mirrorport des Switches mit einer 3. Maschine machen.
Elektrisch ist ja die Frage, wie man die Theorie Stoersignal auf dem Kabel feststellen koennte? Was fuer mein kleines technisches Herz ja das naheliegendste waere.
Gruesse
Thomas
(Sales... ja, ihr macht mir immer das Leben schwer mit Dingen die es noch nicht gibt
)fein(koennte konstruktiv werden), nur bitte auch nicht vergessen, von welchen Datenraten wir hier reden. Das sind Peanuts, meiner Meinung nach. Gerade wenn wir 44.1 vergleichen (500k maximum). Latency ok, aber hier geht es meiner Meinung nach immer noch nicht um RT Daten die abgearbeitet werden muessen(also in dem Prozess des Datenaustausches und da ist das Kabel welches man im unterschied hoert), sondern um Daten die ankommen und verworfen werden koennen.
Kurzes Kabel ok, aber nicht der Latenz wegen
.Diese CPU Thematik macht mir da echt zu schaffen, mehr Umdrehungen mehr Strom dadurch mehr Uebersprechungen?.... Hach da halte ich mich mal raus, ich habe schon immer beim Stealth Player mitgelesen, aber mir fehlt da irgendwie der Dreh mit einem System zu arbeiten, welches OOS ist, und eh seine Problemchen mit dem Threaden hat/hatte. Warum nicht so eine SW auf ein vernuenftiges System aufsetzen und dann mal diese Auslastungsthematik angehen?
Aller Theorie nach koennte man ja nur die Sache mit einem System in Angriff nehmen, auf welchem man Zugriff hat, um genau diese Punkte messen(jaja, wer misst misst mist oder so aehnlich) zu koennen.
Es muss ja nicht alles superaudiophil sein, sondern wir wollen ja die Unterschiede in einen Kausalen Zusammenhang stellen koennen(wenn es zu schlecht ist, bekommt man evtl nichts mit
)Ok bevor jetzt hier jemand mit XP vorprescht..
Ich denke da eher an ein/zwei Linux Systeme, dafuer gibt es meiner Meinung nach mehr Tools zum analysieren.
Dann ein Playersystem(Client) und einen Server.
CPU/mem/IOPS/Latency etc. ueber nmon z.b.
Definition der Testreihen, vor allendingen muss man da ja nun was hoeren
tcpdump zum snoopen, koennte man natuerlich auf einen mirrorport des Switches mit einer 3. Maschine machen.
Elektrisch ist ja die Frage, wie man die Theorie Stoersignal auf dem Kabel feststellen koennte? Was fuer mein kleines technisches Herz ja das naheliegendste waere.
Gruesse
Thomas
Hallo Uli,
bin ich bei Dir (die Technik muss wissen wann sie lügt, beim Sales aehmm, tja)
In der Tat sind selbst bei hochauflösendem Format Audio Format nur 4,xxx oder 8,xxx Mbit an Durchsatz zu verzeichnen. Das sind wirklich Peanuts gegenüber der Transportkapazität (ueber mein Netz liese sich locker Video mit HD Qualität streamen).
Und trotzdem, bleiben wir mal am Delta der Anstiegsflancken (wann wird eine 1 zu einer 1). Da sind mir in der Theorie dann 500 Mhz an garantierter Übertragungskapazität bei Kabeln doch lieber als 50. (Auch wenn mein Router das nicht umsetzen kann und mein Ohr dem Cat5 Kabel den Vorzug gibt). Interessanterweise gibt es von Linn selbst ein paar generelle Empfehlungen.
a) Wired wird vor Wireless der Vorzug gegeben (Linn spricht bei Wireless etwas (imo ,zu allegemein) von nicht garantierter Verbindungsqualität, dem ich bei einer 300Mbit Verbindung einfach mal widerspreche) - Die Bedienung via der Linn App darf natuerlich Wireless geschehen, was ja auch Sinn macht - deshalb überhaupt die Notwendigkeit eines Wireless Routers.
b) Es gibt bei Linn einfache Szenarien zum Aufbau einer Streamer Netztopologie mit NAS , Router , Streamer (Renderer) - aber empfohlen wird der Einsatz eine dedizierten Switches - warum ???? - hier schweigt man sich aus.
c) Linn selbst gibt keine Aussage zu spezifischen Netzdevices (würde auch zu kompliziert, bei den häufigen Wechseln in der Modellpolitik der Netzausrüster) - mündlich habe ich vom Linn Techsupport schon vernommen, dass sie den Einfluss von Kabeln und unterschiedlichen NAS Systemen so nicht bestätigen möchten.
Ich bin kommendes Wochenende bei Linn in Schottland - wenn sich die Gelegenheit ergibt, werde ich die Jungs mal direkt mit meinen "Erfahrungen" konfrontieren - vielleicht laesst sich bei einem guten schottischen Wiskey doch eine persönliches Statement entlocken.
Wie gesagt, ich tue mich mit Messaufbauten und dergleichen schwer. Der Audio Diff Maker ist sicherlich ein interessanter Ansatz - nur , dass hätte ich vor 10 Jahren umsetzen koennen, heute - tja, mein ganzer Messgeräte Park ist schon lange entsorgt, und mir bleibt einfach zu wenig Zeit, da intensiver einzusteigen. Bei mir steht ein Mac Book pro, ein I Pad und mein Dienstlaptop, that's it.
Viele Gruesse
Rainer
bin ich bei Dir (die Technik muss wissen wann sie lügt, beim Sales aehmm, tja
)In der Tat sind selbst bei hochauflösendem Format Audio Format nur 4,xxx oder 8,xxx Mbit an Durchsatz zu verzeichnen. Das sind wirklich Peanuts gegenüber der Transportkapazität (ueber mein Netz liese sich locker Video mit HD Qualität streamen).
Und trotzdem, bleiben wir mal am Delta der Anstiegsflancken (wann wird eine 1 zu einer 1). Da sind mir in der Theorie dann 500 Mhz an garantierter Übertragungskapazität bei Kabeln doch lieber als 50. (Auch wenn mein Router das nicht umsetzen kann und mein Ohr dem Cat5 Kabel den Vorzug gibt). Interessanterweise gibt es von Linn selbst ein paar generelle Empfehlungen.
a) Wired wird vor Wireless der Vorzug gegeben (Linn spricht bei Wireless etwas (imo ,zu allegemein) von nicht garantierter Verbindungsqualität, dem ich bei einer 300Mbit Verbindung einfach mal widerspreche) - Die Bedienung via der Linn App darf natuerlich Wireless geschehen, was ja auch Sinn macht - deshalb überhaupt die Notwendigkeit eines Wireless Routers.
b) Es gibt bei Linn einfache Szenarien zum Aufbau einer Streamer Netztopologie mit NAS , Router , Streamer (Renderer) - aber empfohlen wird der Einsatz eine dedizierten Switches - warum ???? - hier schweigt man sich aus.
c) Linn selbst gibt keine Aussage zu spezifischen Netzdevices (würde auch zu kompliziert, bei den häufigen Wechseln in der Modellpolitik der Netzausrüster) - mündlich habe ich vom Linn Techsupport schon vernommen, dass sie den Einfluss von Kabeln und unterschiedlichen NAS Systemen so nicht bestätigen möchten.
Ich bin kommendes Wochenende bei Linn in Schottland - wenn sich die Gelegenheit ergibt, werde ich die Jungs mal direkt mit meinen "Erfahrungen" konfrontieren - vielleicht laesst sich bei einem guten schottischen Wiskey doch eine persönliches Statement entlocken.
Wie gesagt, ich tue mich mit Messaufbauten und dergleichen schwer. Der Audio Diff Maker ist sicherlich ein interessanter Ansatz - nur , dass hätte ich vor 10 Jahren umsetzen koennen, heute - tja, mein ganzer Messgeräte Park ist schon lange entsorgt, und mir bleibt einfach zu wenig Zeit, da intensiver einzusteigen. Bei mir steht ein Mac Book pro, ein I Pad und mein Dienstlaptop, that's it.
Viele Gruesse
Rainer