Hallo PC-Freunde,
Es ist nicht die einige Prozessorlast die ein Problem des Computer darstelt, aber eben die Schwankungen von Prozesse. Dieses ständige ein- und ausschalten von Duzende von Chipsets die irgendeine Funktion in der Grafikkarte oder im Netzwerk auslöst, ist das eigentliche Problem.
Genau dieses ständige "Ruckeln" in der Stromversorgung ergibt eben unstabilen Signalbearbeitung, und ist z.B.auch der Grund dafür das eine lineare Versorgung nicht bringt, ohne auch den Stromverbrauch ruhiger zu stellen....
Es ist klar dass man einige Dienste abstellen kan die man nicht braucht, aber genau die zwei grössten "Sünder", also die Netzwerktechnik und die grafische Oberfläche, sind die zwei Elemente die unseren Komfort erhöht.
Das cMP2 Projekt ist ja genau darauf angelegt ohne diese Elemente zu funktionieren, und ie Liste von Uli ist dennoch nur ein sehr bescheidener Teil von was machbar ist. Der Takmanager gibt Auskunft darüber wie viel Betriebsystem geladen wird.
In einem standard Win7 sind es knap 700 MB und in einem cMP2 zum vergleich 25MB.
Wer eine Liste darüber haben will was in einen cMP2 abgeschaltet und rausgenommen ist, kann ihn bei mir anfordern, denn die Liste ist um die 800 Massnahmen lang !
Übrigens kann man ja über Geschmack und Design streiten, aber wer nicht weiss wie cMP2 funktioniert, soll die Bedienung nicht kritisieren. Der cicsmemoryplayer ist für Touchcreen und drahtlose Fernbedinung ausgelegt.
Hier einige Videobeispiele für wie cMP2 funktionieren kann :
http://home.tele2.de/my-audio-pc/index-audio-pc.html
http://cmp2-mihaylov.narod.ru/
L.
Win 7 - Welche Dienste abschalten?
Die Bedienung von cMP² ist alles andere als umständlich. Sie ist halt auf das Notwendige reduziert und bietet keine grafischen Möglichkeiten. Wer sich an Cover-Bildchen ergötzen möchte, ist hier sicherlich falsch. Aber das Auffinden und Abspielen von Musik ist wirklich prima gelöst.play-mate hat geschrieben:Übrigens kann man ja über Geschmack und Design streiten, aber wer nicht weiss wie cMP2 funktioniert, soll die Bedienung nicht kritisieren. Der cicsmemoryplayer ist für Touchcreen und drahtlose Fernbedinung ausgelegt.
Gruß,
Stefan
Hallo Fujak
Stimmt leider. Und als Konsument bleibt einem nix anderes drüber, als einem Mammut eine Schlankheitskur zu verordnen, statt gleich die schlanke Ballettdiva zu verwenden.Fujak hat geschrieben:Hallo Bernd,
es bleibt dann leider unter Linux immer noch die ungelöste Treiber-Frage für die meisten USB-Interfaces.
Grüße
Fujak
-
vincent kars
- Aktiver Hörer
- Beiträge: 154
- Registriert: 15.03.2011, 16:50
- Kontaktdaten:
-
vincent kars
- Aktiver Hörer
- Beiträge: 154
- Registriert: 15.03.2011, 16:50
- Kontaktdaten:
Vincent Kars bringt eine gewisse Perspektive in diese Disskussion, denn es geht ja in Wirklichkeit um die gute alte Jitterproblematik.
Und natürlich um wie gut ein DAC und die Schnittstelle mit Jitter umgehen bzw. zurückweisen kann.
Eine S/PDIF Übertragung muss am besten nahezu Jitterfrei sein, jedoch mit der steigenden Anzahl von DACs mit asynchroner USB Transmission, relativiert sich ja auch die Sensibilität/Problematik von Jitter des Computeres/Quelle.
LG. leif
Und natürlich um wie gut ein DAC und die Schnittstelle mit Jitter umgehen bzw. zurückweisen kann.
Eine S/PDIF Übertragung muss am besten nahezu Jitterfrei sein, jedoch mit der steigenden Anzahl von DACs mit asynchroner USB Transmission, relativiert sich ja auch die Sensibilität/Problematik von Jitter des Computeres/Quelle.
LG. leif
Hallo Leif,
Sorry, aber ich bleibe hartnäckig
wenn es um das „Objektivieren“ der Auswirkungen auf den Klang geht.
Ich vertraue zwar auf mein subjektives „Lauchometer“, aber beim Nachvollziehen von
„800 Massnahmen“ wäre mein „Lauchometer“ deutlich überfordert.
Ich habe jetzt selbst einige Optimierungen mit sehr unterschiedlichen Ergebnis ausprobiert:
Abschalten W7 Dienste ->
mit Tools klar nachvollziehbar, weniger Prozesse und mehr freie Ressourcen ->
Auswirkung auf den Klang marginal
Abschalten Netzwerkadapter ->
im Taskmanager etc. nicht zu erkennen, aber Latency-Check zeigt Verbesserung ->
Auswirkung auf den Klang marginal
ASIO Buffer Größe verringert ->
ich konnte mit Tools ( bisher ) keine Veränderung erkennen ->
Auswirkung auf den Klang von den drei Maßnahmen vergleichsweise am größten,
siehe Thread „USB DAC Asus Xonar Essence One“
Dennoch machen sich manche Massnahmen bemerkbar andere weniger.
Ist die einzige Möglichkeit zu analysieren, eine Jitter Messeung am Analogausgang des DACs ?
Viele Grüße
Maximilian
das sieht ja wirklich sehr sehr gut aus.Übrigens haben wir auch einen Latency-Check mit cMP2 vorzuweisen
Sorry, aber ich bleibe hartnäckig
wenn es um das „Objektivieren“ der Auswirkungen auf den Klang geht.
Ich vertraue zwar auf mein subjektives „Lauchometer“, aber beim Nachvollziehen von
„800 Massnahmen“ wäre mein „Lauchometer“ deutlich überfordert.
Ich habe jetzt selbst einige Optimierungen mit sehr unterschiedlichen Ergebnis ausprobiert:
Abschalten W7 Dienste ->
mit Tools klar nachvollziehbar, weniger Prozesse und mehr freie Ressourcen ->
Auswirkung auf den Klang marginal
Abschalten Netzwerkadapter ->
im Taskmanager etc. nicht zu erkennen, aber Latency-Check zeigt Verbesserung ->
Auswirkung auf den Klang marginal
ASIO Buffer Größe verringert ->
ich konnte mit Tools ( bisher ) keine Veränderung erkennen ->
Auswirkung auf den Klang von den drei Maßnahmen vergleichsweise am größten,
siehe Thread „USB DAC Asus Xonar Essence One“
vermutlich ja, da es bei einem externen DAC kaum andere Beeinflussungsmöglichkeiten gibt.denn es geht ja in Wirklichkeit um die gute alte Jitterproblematik.
das sehe ich auch so, mein „USB DAC Asus Xonar Essence One“ dürfte dazugehören.jedoch mit der steigenden Anzahl von DACs mit asynchroner USB Transmission, relativiert sich ja auch die Sensibilität/Problematik von Jitter des Computeres/Quelle.
Dennoch machen sich manche Massnahmen bemerkbar andere weniger.
Ist die einzige Möglichkeit zu analysieren, eine Jitter Messeung am Analogausgang des DACs ?
Viele Grüße
Maximilian
-
vincent kars
- Aktiver Hörer
- Beiträge: 154
- Registriert: 15.03.2011, 16:50
- Kontaktdaten:
There are 2 options.
One is to record e.g. the SPDIF out.
This is not too difficult.
It will tell you what happens at bit level and allows you to rule out that audible difference like between WAV and FLAC or between various players are due to differences in content.
In general these type of testing yields zero difference at bit level.
It doesn’t cover the timing part but at least it rules out the bit part.
This is pretty useful as a lot of people struggle to understand that differences in sound quality are not necessarily due to the value of the bits.
As PCM is sample+sample rate the fluctuations in sample rate (jitter) is the only one left to explain possible differences.
Unfortunately jitter test are rather complex and requires advanced measurement equipment.
Often AP is used but the price tag is prohibitive for the average user.
The AES never come to an agreement about what the right jitter test should be.
A guy like Gordon Rankin claims to have measured the output using Wavecrest DTS and a Standford 760 FFT and couldn’t see a difference between WAV and FLAC
He also claims that 82% of the audience heard a difference between WAV and FLAC
http://thewelltemperedcomputer.com/KB/WAV-FLAC.htm
Go figure.
An alternative is of course a unsighted test, preferably DBT or ABX
It is not easy to stage one meeting all the rigor of scientific testing.
My personal preference is rapid AB.
Rapid enough to have all in short-term memory
But if you do have to reconfigure your system between A and B you can forget the “rapid”
And beside if you do this yourself you know what is playing.
Even if we expect not to have any expectation bias at all, our perception might think different.
We are excellent in deluding ourselves.
But it would be great if one day a guy pops up with measured differences at jitter level in relation to PC configuration.
One is to record e.g. the SPDIF out.
This is not too difficult.
It will tell you what happens at bit level and allows you to rule out that audible difference like between WAV and FLAC or between various players are due to differences in content.
In general these type of testing yields zero difference at bit level.
It doesn’t cover the timing part but at least it rules out the bit part.
This is pretty useful as a lot of people struggle to understand that differences in sound quality are not necessarily due to the value of the bits.
As PCM is sample+sample rate the fluctuations in sample rate (jitter) is the only one left to explain possible differences.
Unfortunately jitter test are rather complex and requires advanced measurement equipment.
Often AP is used but the price tag is prohibitive for the average user.
The AES never come to an agreement about what the right jitter test should be.
A guy like Gordon Rankin claims to have measured the output using Wavecrest DTS and a Standford 760 FFT and couldn’t see a difference between WAV and FLAC
He also claims that 82% of the audience heard a difference between WAV and FLAC
http://thewelltemperedcomputer.com/KB/WAV-FLAC.htm
Go figure.
An alternative is of course a unsighted test, preferably DBT or ABX
It is not easy to stage one meeting all the rigor of scientific testing.
My personal preference is rapid AB.
Rapid enough to have all in short-term memory
But if you do have to reconfigure your system between A and B you can forget the “rapid”
And beside if you do this yourself you know what is playing.
Even if we expect not to have any expectation bias at all, our perception might think different.
We are excellent in deluding ourselves.
But it would be great if one day a guy pops up with measured differences at jitter level in relation to PC configuration.
Es gibt gute Gründe dafür das es keine "absoluten" Jittermessungen gibt, denn man muss die Verflechtung von Einflüssen verstehen.
-oder jedenfalls sich die Problematik verinnerlichen.
In einem analogen Signalfluss wird die Amplitude eines Zeitrichtigen (analogem) Signal in elektrischer Spannung transportiert.
Wie das Wasser in einem Fluss.
Streng genommen ist ein S/PDIF Signal auch eine Art von Datenfluss, das zwar in digitalen Bits & Bytes zerlegt ist, aber dennoch einem strengem, zeitlichem Regime unterliegt.
Aber nicht so in einem Computer !
In einem Computer werden eine Menge kleine Eimer mit Bits und Bytes als Daten transportiert.
Das ist ein gravierender Unterschied.
Das Betriebssystem, der CPU Prozessor und die dazugehörende Chipsets regeln eine schier unglaubliche Menge von Bits&Bytes in Megaherz Geschwindigkeit : einiges in einem Audioprogram vieleicht, aber das Meiste in Updates, Security, Dienste, Netwerk etc. etc .....Das ist alles unglaublich unübersichtlich.
Alle diese Befehle gehen über den Prozessor als "Dirigent", aber jeder kleine Chip und Controller wird ständig ein- und ausgeschaltet. Tausinde, ja gar zigtausindmal in der Sekunde.
Alle diese Prozesse daueren Fraktionen von Milli- und Microsekunden, und der Prozessor muss ständig darauf warten dass die einzelnen Chips ihre Kalkulationen ausführen.
Das ist ein elektronischer Armeisenhaufen hoch 10 !
In diesem Armeisenhaufen, bündeln sich Abläufe die, wenn zusammengelegt, viele, viele Latenzen und Spannungsfluktationen sich verselbständigen und die zu Jitter führen, denn alle diese Chips befördern nicht analogen Strom.
Sie befördern Daten !
Und wenn diese Bytes von Daten in Fluktation in bestimmten Mengen auftreten, ergeben sich Wellen und Muster von elektronischer Beanspruchung.....und sollche können bestimmte, hörbare Frequenzen haben.
Das sind die Ursachen warum Jitter in einem Computer auftritt, und warum Software darauf einen Einfluss hat.
Weniger Funktionen = weniger Armeisen = weniger Stromverbrauch = weniger unnötige Aktivität -> besserer Sound !
Deshalb : weniger Software = weniger Jitter
-oder jedenfalls sich die Problematik verinnerlichen.
In einem analogen Signalfluss wird die Amplitude eines Zeitrichtigen (analogem) Signal in elektrischer Spannung transportiert.
Wie das Wasser in einem Fluss.
Streng genommen ist ein S/PDIF Signal auch eine Art von Datenfluss, das zwar in digitalen Bits & Bytes zerlegt ist, aber dennoch einem strengem, zeitlichem Regime unterliegt.
Aber nicht so in einem Computer !
In einem Computer werden eine Menge kleine Eimer mit Bits und Bytes als Daten transportiert.
Das ist ein gravierender Unterschied.
Das Betriebssystem, der CPU Prozessor und die dazugehörende Chipsets regeln eine schier unglaubliche Menge von Bits&Bytes in Megaherz Geschwindigkeit : einiges in einem Audioprogram vieleicht, aber das Meiste in Updates, Security, Dienste, Netwerk etc. etc .....Das ist alles unglaublich unübersichtlich.
Alle diese Befehle gehen über den Prozessor als "Dirigent", aber jeder kleine Chip und Controller wird ständig ein- und ausgeschaltet. Tausinde, ja gar zigtausindmal in der Sekunde.
Alle diese Prozesse daueren Fraktionen von Milli- und Microsekunden, und der Prozessor muss ständig darauf warten dass die einzelnen Chips ihre Kalkulationen ausführen.
Das ist ein elektronischer Armeisenhaufen hoch 10 !
In diesem Armeisenhaufen, bündeln sich Abläufe die, wenn zusammengelegt, viele, viele Latenzen und Spannungsfluktationen sich verselbständigen und die zu Jitter führen, denn alle diese Chips befördern nicht analogen Strom.
Sie befördern Daten !
Und wenn diese Bytes von Daten in Fluktation in bestimmten Mengen auftreten, ergeben sich Wellen und Muster von elektronischer Beanspruchung.....und sollche können bestimmte, hörbare Frequenzen haben.
Das sind die Ursachen warum Jitter in einem Computer auftritt, und warum Software darauf einen Einfluss hat.
Weniger Funktionen = weniger Armeisen = weniger Stromverbrauch = weniger unnötige Aktivität -> besserer Sound !
Deshalb : weniger Software = weniger Jitter
-
uli.brueggemann
- Aktiver Hersteller
- Beiträge: 4659
- Registriert: 23.03.2009, 15:58
- Wohnort: 33649
- Kontaktdaten:
Das Beispiel mit dem Wasser ist vielleicht nützlich.
Stellen wir uns vor, dass wir aus einem Wasserhahn einen konstanten Wasserstrahl fliessen lassen möchten.
Nun muss das Wasser ja irgendwoher kommen, es könnte auch aus einem Bach stammen. Nun regnet es manchmal, manchmal nicht. Manchmal ist Sturmflut, manchmal Trockenzeit. Manchmal lassen andere ihre Badewannen vollaufen, manchmal braucht das AKW nebenan reichlich Wasser zur Kühlung beim Beinahe-GAU.
Anders geht es im Prozessor mit der Entstehung und Verteilung von Bits und Bytes auch nicht zu. Trotzdem soll nun aus der Soundkarte ein konstanter Musikstrom fliessen, also ohne Jitter.
Was tut man nun im Wasserwerk? Man sammelt das Wasser in einem Becken. Das kann sich bis zu einem grossen Stausee ausweiten. Es kann dann drumherum die Sonne scheinen, regnen, stürmen oder schneien. Der Pegel im Becken wird sich heben und senken. Aber trotzdem wird es möglich damit, dass aus unserem Wasserhahn der konstante Wasserstahl fliesst. Zumindest solange im Becken Wasser vorhanden ist.
Übertragen auf die digitale Welt heisst das doch: wir brauchen einen Puffer. In den die CPU Daten reinlädt, wann sie will. Ob mit oder ohne zig-tausend Unterbechungen, Services oder Prozesse. Die einzige Bedingung ist, dass immer genügend Daten im Puffer vorhanden sind. Dann kann die Soundkarte ihrerseits Daten aus dem Puffer auslesen und einen konstanten Datenstrom fliessen lassen.
Der vielleicht kleine aber feine Unterschied: beim Wasserbecken fliessen die Zuströme über beliebige Leitungen, nicht jedoch über den Wasserhahn, wo Wasser entnommen wird. In diesem Sinn bräuchte der Datenpuffer ebenfalls getrennte Daten- und Adressleitungen für Schreiben und Lesen. Mit einem Wechselpufferkonzept kommt man dem schon halbwegs nahe. Aber üblicherweise teilen sich CPU und Soundkarte trotzdem Daten- und Adressleitungen. Also muss der Zugriff darauf geregelt werden. Was letztendlich trotzdem Kollisionen verursacht.
Solange das passiert, wird es Jitter geben. Mit steigender Anzahl an Prozessen wird die Wahrscheinlichkeit größer. Insofern hilft das Minimieren.
Weshalb es aber kein wirkliches Konzept gibt, das dafür sorgt, dass die Soundkarte gemütlich und unbeeinflusst von CPU und deren Prozessen inkl. Belastung der Datenleitungen die Puffer ausliest, ist mir unkar. Ein Erklärungsmodell wäre vielleicht, das man wiederum keine grossen Puffer möchte. Bis der nämlich gefüllt ist, entsteht eine entsprechende Latenz. Was beim Musikhören egal ist, aber nicht im Live-Einsatz.
Grüsse
Uli
Stellen wir uns vor, dass wir aus einem Wasserhahn einen konstanten Wasserstrahl fliessen lassen möchten.
Nun muss das Wasser ja irgendwoher kommen, es könnte auch aus einem Bach stammen. Nun regnet es manchmal, manchmal nicht. Manchmal ist Sturmflut, manchmal Trockenzeit. Manchmal lassen andere ihre Badewannen vollaufen, manchmal braucht das AKW nebenan reichlich Wasser zur Kühlung beim Beinahe-GAU.
Anders geht es im Prozessor mit der Entstehung und Verteilung von Bits und Bytes auch nicht zu. Trotzdem soll nun aus der Soundkarte ein konstanter Musikstrom fliessen, also ohne Jitter.
Was tut man nun im Wasserwerk? Man sammelt das Wasser in einem Becken. Das kann sich bis zu einem grossen Stausee ausweiten. Es kann dann drumherum die Sonne scheinen, regnen, stürmen oder schneien. Der Pegel im Becken wird sich heben und senken. Aber trotzdem wird es möglich damit, dass aus unserem Wasserhahn der konstante Wasserstahl fliesst. Zumindest solange im Becken Wasser vorhanden ist.
Übertragen auf die digitale Welt heisst das doch: wir brauchen einen Puffer. In den die CPU Daten reinlädt, wann sie will. Ob mit oder ohne zig-tausend Unterbechungen, Services oder Prozesse. Die einzige Bedingung ist, dass immer genügend Daten im Puffer vorhanden sind. Dann kann die Soundkarte ihrerseits Daten aus dem Puffer auslesen und einen konstanten Datenstrom fliessen lassen.
Der vielleicht kleine aber feine Unterschied: beim Wasserbecken fliessen die Zuströme über beliebige Leitungen, nicht jedoch über den Wasserhahn, wo Wasser entnommen wird. In diesem Sinn bräuchte der Datenpuffer ebenfalls getrennte Daten- und Adressleitungen für Schreiben und Lesen. Mit einem Wechselpufferkonzept kommt man dem schon halbwegs nahe. Aber üblicherweise teilen sich CPU und Soundkarte trotzdem Daten- und Adressleitungen. Also muss der Zugriff darauf geregelt werden. Was letztendlich trotzdem Kollisionen verursacht.
Solange das passiert, wird es Jitter geben. Mit steigender Anzahl an Prozessen wird die Wahrscheinlichkeit größer. Insofern hilft das Minimieren.
Weshalb es aber kein wirkliches Konzept gibt, das dafür sorgt, dass die Soundkarte gemütlich und unbeeinflusst von CPU und deren Prozessen inkl. Belastung der Datenleitungen die Puffer ausliest, ist mir unkar. Ein Erklärungsmodell wäre vielleicht, das man wiederum keine grossen Puffer möchte. Bis der nämlich gefüllt ist, entsteht eine entsprechende Latenz. Was beim Musikhören egal ist, aber nicht im Live-Einsatz.
Grüsse
Uli
Hallo Uli,
Obwohl wir ja schon die Big-Ben Re-Clocking Diskussion gehabt haben, so ist Zwischenspeicher auch nicht die ultimative Lösung.
Buffer aka. Re-Clocking diskutieren wir auch hier : http://aktives-hoeren.de/viewtopic.php? ... acb7c1ce93.
Aber ehrlich gesagt, ich verstehe nicht warum die These mit dem abschalten von Diensten, Software und Treiber, so kontroversiel ist ???
Gruss Leif
Obwohl wir ja schon die Big-Ben Re-Clocking Diskussion gehabt haben, so ist Zwischenspeicher auch nicht die ultimative Lösung.
Buffer aka. Re-Clocking diskutieren wir auch hier : http://aktives-hoeren.de/viewtopic.php? ... acb7c1ce93.
Aber ehrlich gesagt, ich verstehe nicht warum die These mit dem abschalten von Diensten, Software und Treiber, so kontroversiel ist ???
Gruss Leif
-
uli.brueggemann
- Aktiver Hersteller
- Beiträge: 4659
- Registriert: 23.03.2009, 15:58
- Wohnort: 33649
- Kontaktdaten:
Hallo Leif,
Buffering und Reclocking sind ZWEI Paar Schuhe. Es würde Sinn machen, sich das zu vergegenwärtigen und in Diskussionen nicht zu vermischen !
Das Buffering erfüllt den Zweck, den Ausgangsdatenstrom vom Eingangsdatenstron zu entkoppeln. Wenn genügend Daten im Puffer sind, dann kann das Auffüllen beliebigst passieren. Das Auslesen kann dann kontinuierlich erfolgen.
Extrembeispiel: Du kannst Deine Festplatte zu beliebigsten Zeiten mit Musiktracks füllen. Beim Abspielen kommt es nur darauf an, dass die Festplatte allein zum Lesen des Tracks verfügbar ist. Das sollte doch klar sein. In realita greifen aber wiederum tausend andere Prozesse auf die Festplatte zu.
Angenommen wir hätten einen Puffer, der gefüllt ist und sonst durch nichts weiteres gestört wird. Dann erfolgt nun ein Auslesevorgang der seinerseits ein zeitlicher Vorgang ist. Dieser Vorgang wird durch die Clock der Soundkarte gesteuert und die Daten werden dann z.B. gemäss spdif-Spezifikation aufbereitet und verschickt. Wenn dieser Vorgang verjittert ist, hilft es auch nichts, dass der Puffer sauber ausgelesen werden kann. Dann wäre ein Reclocking angebracht.
Also zwei Paar Schuhe, die unabhängig voneinander zu optimieren wären.
Uli
Buffering und Reclocking sind ZWEI Paar Schuhe. Es würde Sinn machen, sich das zu vergegenwärtigen und in Diskussionen nicht zu vermischen !
Das Buffering erfüllt den Zweck, den Ausgangsdatenstrom vom Eingangsdatenstron zu entkoppeln. Wenn genügend Daten im Puffer sind, dann kann das Auffüllen beliebigst passieren. Das Auslesen kann dann kontinuierlich erfolgen.
Extrembeispiel: Du kannst Deine Festplatte zu beliebigsten Zeiten mit Musiktracks füllen. Beim Abspielen kommt es nur darauf an, dass die Festplatte allein zum Lesen des Tracks verfügbar ist. Das sollte doch klar sein. In realita greifen aber wiederum tausend andere Prozesse auf die Festplatte zu.
Angenommen wir hätten einen Puffer, der gefüllt ist und sonst durch nichts weiteres gestört wird. Dann erfolgt nun ein Auslesevorgang der seinerseits ein zeitlicher Vorgang ist. Dieser Vorgang wird durch die Clock der Soundkarte gesteuert und die Daten werden dann z.B. gemäss spdif-Spezifikation aufbereitet und verschickt. Wenn dieser Vorgang verjittert ist, hilft es auch nichts, dass der Puffer sauber ausgelesen werden kann. Dann wäre ein Reclocking angebracht.
Also zwei Paar Schuhe, die unabhängig voneinander zu optimieren wären.
Uli
Hallo Leif,
Jedoch muss man den Nutzen aus meiner Sicht auch immer abwägen mit dem Nutzen einer weiteren Optimierungsmöglichkeit, nämlich die digitale Hardware. Bei mir z.B. ist der klangliche Zugewinn der Software-Optimierung zumindest in meinem Setup bei weitem nicht so groß wie der klangliche Nutzen, den ich über die Optimierung der digitalen Hardware erzielt habe (Reclocker, optimierte Stromversorgungen, SPDIF-Kabel etc.). Das schließt aber bei mir nicht aus, dass ich nicht auch Software-Optimierung betreibe - soweit sie klangliche Verbesserungen bringt.
Software-Optimierung und Hardware-Optimierung sind ja nicht ein Entweder-Oder sondern ein Sowohl-als auch. Ersteres ist tendenziell zeit- und nervenintensiver, spart aber Geld, letzteres ist kostenintensiver, spart aber Zeit und Nerven. In welchem Mischungsverhältnis jemand die beiden Optimierungswege beschreitet, muss jeder für sich entscheiden - ich glaube nicht, dass dies sinnvoll im grundsätzlichen zu diskutieren wäre, wie es an einigen Stellen im Thread versucht wurde.
@ All: Insofern: um an dieser Stelle wieder zum Thread-Titel überzuleiten: Wer sich nun entschieden hat, eine klangliche Optimierung durch Abschalten von Diensten und Systembestandteilen von Win7 zu erreichen, für den wäre doch nun die bereits angesprochene systematische Auflistung aller Dienste und System-Parts hilfreich.
Ich denke, dass es sinnvoll ist, nun von den (meist fruchtlosen) Grundsatz-Diskussionen wegzukommen und mehr die praktische Umsetzung des Thread-Titels zu erörtern: Welche Dienste unter Win 7 kann man abschalten, um eine klangliche Verbesserung zu erhalten, und dies ohne die grundlegende Funktionalität des Systems zu gefährden.
Grüße
Fujak
für mich ist der Sinn des Abschaltens von Diensten unter Win7 (und nur auf dieses OS bezieht sich ja der Thread-Titel) nicht kontrovers, sondern auch technisch nachvollziehbar. Es gab ja nun genügend (interessante wie schlüssige) Erklärungsansätze in diesem und anderen Threads.play-mate hat geschrieben:Aber ehrlich gesagt, ich verstehe nicht warum die These mit dem abschalten von Diensten, Software und Treiber, so kontroversiel ist ???
Jedoch muss man den Nutzen aus meiner Sicht auch immer abwägen mit dem Nutzen einer weiteren Optimierungsmöglichkeit, nämlich die digitale Hardware. Bei mir z.B. ist der klangliche Zugewinn der Software-Optimierung zumindest in meinem Setup bei weitem nicht so groß wie der klangliche Nutzen, den ich über die Optimierung der digitalen Hardware erzielt habe (Reclocker, optimierte Stromversorgungen, SPDIF-Kabel etc.). Das schließt aber bei mir nicht aus, dass ich nicht auch Software-Optimierung betreibe - soweit sie klangliche Verbesserungen bringt.
Software-Optimierung und Hardware-Optimierung sind ja nicht ein Entweder-Oder sondern ein Sowohl-als auch. Ersteres ist tendenziell zeit- und nervenintensiver, spart aber Geld, letzteres ist kostenintensiver, spart aber Zeit und Nerven. In welchem Mischungsverhältnis jemand die beiden Optimierungswege beschreitet, muss jeder für sich entscheiden - ich glaube nicht, dass dies sinnvoll im grundsätzlichen zu diskutieren wäre, wie es an einigen Stellen im Thread versucht wurde.
@ All: Insofern: um an dieser Stelle wieder zum Thread-Titel überzuleiten: Wer sich nun entschieden hat, eine klangliche Optimierung durch Abschalten von Diensten und Systembestandteilen von Win7 zu erreichen, für den wäre doch nun die bereits angesprochene systematische Auflistung aller Dienste und System-Parts hilfreich.
Ich denke, dass es sinnvoll ist, nun von den (meist fruchtlosen) Grundsatz-Diskussionen wegzukommen und mehr die praktische Umsetzung des Thread-Titels zu erörtern: Welche Dienste unter Win 7 kann man abschalten, um eine klangliche Verbesserung zu erhalten, und dies ohne die grundlegende Funktionalität des Systems zu gefährden.
Grüße
Fujak