Fujak (Neumann KH 420 + Sub Teufel M11000 & Klipsch R-115SW)

[Fujak]

Hallo Maximilian,

Steigerung um 10 Punkte: CPU-Core-Allocation + CPU-Process_Priority + Win32 Priority Separation

den Punkt habe ich nur zum Teil verstanden, CPU-Core-Allocation ist klar, CPU-Process_Priority was ist hier der Unterschied zur Process_Priority und auf welchen Prozess bezieht sich das, auf welche Priority hast Du geändert? Win32 Priority was ist damit gemeint?

So wie in meiner Konfiguration beschrieben:

CPU-Process-Priority:
Ebenfalls mit dem Programm "Process Lasso" habe ich die Priorisierung der unterschiedlichen Prozesse vorgenommen. Die einzigen Prozesse mit Echtzeit-Priorität haben bei mir die beiden CMP-Komponenten CMP-Shell und Cplay bekommen; alle anderen Prozesse sind normal, niedrig oder hoch. Damit ist es möglich, cMP² garantiert unterbrechungsfrei in der höchsten Qualitätsstufe (siehe unten) laufen zu lassen, auch wenn man die CPU ein wenig runtertaktet. Bei den Systemprozessen sollte man allerdings genau wissen, was man tut. Ansonsten läuft man in Gefahr sein System unbrauchbar zu machen. Die diversen svchost.exe-Prozesse sollte man auf ihre Subthreads untersuchen, um zu entscheiden, was wie priorisiert werden kann. Ich möchte hier bewusst keine Priorisierungs-Empfehlungen geben.

Win32 Priority Separation :
Diese Einstellung ergänzt die CPU-Process-Priority und wird in der Registry vorgenommen. Sie bewirkt, dass von Windows ein größerer Datei-Cache angelegt wird, sodass sichergestellt wird, dass keine Teile des Kernels auf der Festplatte ausgelagert werden.

Grüße
Fujak

[play-mate]

Hallo Maximillian & Fujak,

Ein kleiner Kommentar zur eurer Diskussion über Prozess Priority :

cics beschreibt die Funktionen vom cMP Program auf der englischen Seite von cMP². Teils ersetzt cMP ja die Windowsoberfläche und schaltet das Dateiensystem und den Explorer ab, aber es geht auch um weitere Prioritäten im System bzw. die Distribution von angewannten Cores.

Er sagt im Kapitel 11 folgendes :

....cMP is a replacement for Explorer that aims to maximise the quality of audio reproduction by reducing the runtime ‘footprint’ and thus motherboard activity in general. cMP improves audio performance through:

1.not using the ‘Welcome’ screen (this must be manually done) and its associated bloat;

2.preventing Taskbar processes from starting;

3.making several low-level ‘runtime’ configuration changes which cannot readily be made by other means. Some are made when cMP is launched, others, such as the suspension of svchost and/or lsass, when a suitable music player is launched by cMP;

4.optimising L1 Data & Instruction cache for audio. On a multi-processor platform, the Optimise > Critical setting locks the most critical audio thread to CPU1. Although the load on this is insignificant, the setting removes need for a real-time operating system;

5.freeing up RAM;

6.providing facilities for a touchscreen, remote control and library management.

- welches in kürze Bedeutet dass wenn cMP gestartet wird, konfiguriert cMP alle diese Prozesse, egal wie diese manuell gesetzt sein mögen.

Gruß Leif

[Fujak]

Hallo Leif,

ich vermute, dass diese Angaben sich auf WinXP beziehen; denn wenn ich in Win8 die Process-Priority während des Betriebes beobachte, bleiben die cMP²-Prozesse unverändert - was man leider auch daran hört, dass es in der klanglichen Maximalkonfiguration zu Aussetzern kommen kann. Erst wenn ich Process-Lasso einsetze, laufen die Prioritäten in die richtige Richtung, was man auch am saubereren Klang hören kann.

Grüße
Fujak

[mm2]

Hallo Fujak,

danke, die Infos waren bei mir nicht mehr im Cache Speicher.

Jetzt bin ich mal auf Deinen Latency Vegleich gespannt. Auch wenn mehrere Kerne die Sicht auf die eigentlichen Latency Verursacher erschweren. Ich habe mich weniger an der "Latency" sondern mehr an der "highest execution time" der Dienste und Prozesse orientiert. Das Eregbnis sieht man aber auch in der Latency.

Zu den Prozessen die hohe Priorität haben sollten, gehört für mich an erste Steller der Treiber der die Daten zum DAC übetragt. Also bei mir der ASIO Treiber, bei Dir der hiface Treiber. Dennoch nicht leicht zu finden, welcher Prozess/Thread das eigentlich ist.

Viele Grüße

[Fujak]

Hallo Maximilian,

ich melde mich zurück von der Messfront.

Jetzt bin ich mal auf Deinen Latency Vegleich gespannt.

Das kannst Du auch. Denn das Ergebnis ist absolut überraschend:
Latency Win XP (minlogon): 20-25µs
Latency Win 7 64bit: 70-80µs
Latency Win 8 64bit: 1000µs

Es ist mir bislang nicht gelungen herauszufinden, was diese extrem hohe Latency erzeugt. Ich habe alles Schritt für Schritt deaktiviert, deinstalliert etc.. Selbst das völlig nackte System ohne Anwendungsprogramme und ohne angeschlossene Hardware-Peripherie erzeugt diesen Wert - so als sei dies systemimmanent.

Die Ironie der ganzen Geschichte ist ja noch obendrein, dass Win8 sich von den 3 OS am besten anhört. Ich bin gespannt, welche Latency die endgültige Version zustande bringt, welche offiziellen Verkaufsstart am 26.10. haben wird.

Zu den Prozessen die hohe Priorität haben sollten, gehört für mich an erste Steller der Treiber der die Daten zum DAC übetragt. Also bei mir der ASIO Treiber, bei Dir der hiface Treiber. Dennoch nicht leicht zu finden, welcher Prozess/Thread das eigentlich ist.

Ich glaube nicht, dass man so vorgehen kann. Der Treiber ist keine eigenständige Anwendung wie ein Dienst (höchstens dessen Benutzeroberfläche zum Einstellen von Parametern); da wirken mehrere Prozesse zusammen. Aber wenn Du dennoch etwas relevantes gefunden hast, würde mich das interessieren.

Grüße
Fujak

[mm2]

Hallo Fujak,

Das kannst Du auch. Denn das Ergebnis ist absolut überraschend:
Latency Win XP (minlogon): 20-25µs
Latency Win 7 64bit: 70-80µs
Latency Win 8 64bit: 1000µs

das ist doch überraschend deutlich und anders als erwartet, allerdings ist nicht nur der maximal Wert interessant, sondern auch der zeitliche Verlauf der Latency. Kannst Du bitte ca. 20sek von W8 posten?

Es ist mir bislang nicht gelungen herauszufinden, was diese extrem hohe Latency erzeugt.

Auch ohne Diagnose würde ich schwer auf einen Festplatten-, Grafiktreiber etc. tippen.

Ich habe alles Schritt für Schritt deaktiviert, deinstalliert etc..

Es gibt dazu ein Tool mit dem man den/die Verursacher relativ schnell herausbekommt, es heißt LatencyMon siehe hier: http://www.resplendence.com/latencymon. In diesem Tool auf „Drivers“ gehen und wie oben genannt auf die "highest execution time" achten und Du hast die Verursacher. Bin gespannt was es bei Dir ist?

Der Treiber ist keine eigenständige Anwendung wie ein Dienst (höchstens dessen Benutzeroberfläche zum Einstellen von Parametern); da wirken mehrere Prozesse zusammen. Aber wenn Du dennoch etwas relevantes gefunden hast, würde mich das interessieren.

Bei mir heißt der Treiber asusstu.sys mit weiteren Tools kann man sehen, dass dieser Treiber auch als Thread unter dem Prozess „system“ auftaucht.

Viele Grüße

[uli.brueggemann]

Windows 8 Compatibility: The DPC latency utility runs on Windows 8 but does not show correct values. The output suggests that the Windows 8 kernel performs badly and introduces a constant latency of one millisecond which is not the case in practice. DPCs in the Windows 8 kernel behave identical to Windows 7. The utility produces incorrect results because the implementation of kernel timers has changed in Windows 8 which causes a side effect with the measuring algorithm used by the utility. Thesycon is working on a new version of the DPC latency utility and will make it available on this site as soon as it is finished.

Gruss
Uli

[Fujak]

Hallo Uli,

vielen Dank für die doch aufschlussreiche information; das entspricht auch meinem Wert, der konstant bei 1000µs (+/-5µs) steht, und zwar egal, was ich deaktiviere oder deinstalliere.

Dennoch werde ich mal mit dem von Maximilian verlinkten Tool (danke @ Maximilian!) dem System auf den Zahn fühlen - in der Hoffnung, dass dieses Tool auch auf Win8 korrekt funktioniert.

Grüße
Fujak

[uli.brueggemann]

Hallo Fujak,

vermutlich ist xperf das viel bessere Analysetool (obwohl so komplex, dass es eigentlich schon zuviel ist und man ein Studium für braucht).

Und - dann weiss man was und kommt trotzdem nicht weiter

Beispiel:


Ich hab seit langem Dropouts und weiss nicht warum. Jetzt hab ich ein Bild davon, klar zu erkennen. Der Firewire-Treiber hat Aussetzer. Aber wieso? Und was dagegen tun? Hab es schon mit drei unterschiedlichen Treibern (Hersteller, Windows OHCI, Windows OHCI Legacy) versucht.

Es ist übrigens Win7x64.

Grüsse
Uli

[Fujak]

Hallo Uli,

das Windows eigene Analysetool kenne ich auch, aber es ist aus meiner Sicht oversized für die Infos, die wir brauchen.

Was Dir helfen könnte bei Deinem Dropout-Problem wäre aus meiner Sicht das Tool Process-Lasso, mit dem Du Prozess-Prioritäten ändern kannst. Irgendein Prozess reißt alle Ressourcen an sich, sodass für den Audio-Prozess nicht mehr genug bleibt. Ich würde hier auch nicht das Problem beim Treiber sondern bei der Abspielsoftware suchen. Möglicherweise kommst Du schon zum Ziel, wenn Du deren Priorität ("hoch" oder "Echtzeit") erhöhst und die Automatische Thread-Priorität deaktivierst. Falls das nichts hilft, würde ich zusätzlich die Audioanwendungen auf einen Kern exklusiv zuteilen.

Grüße
Fujak

[Udor]

Hallo Fujak

ich hatte mal vor einigen Wochen die Trial-Version getestet. Sie konnte bei weitem nicht mithalten. Wenn Du aus verständlichen Gründen bei JRiver bleiben möchtest, kannst Du ja JPlay als Engine via Plugin einbinden. Damit dürftest Du eine deutliche Klangsteigerung erreichen, und kannst zugleich den vertrauten Bedienkomfort behalten.

Die Jplay Engine hab ich mit Jriver nicht ans laufen bekommen allerdings hab ich mich nicht sehr lange damit beschäftigt da in verbindung mit Jplay etc. das ganze Convolving auf der Strecke bleibt. Deswegen ist das eh kein Thema für mich.

Noch mal zurück zu Processlasso. Da ich ungerne zwei Processortools laufen lassen möchte(ich nutze ja im moment noch CrystalCPUID um den Takt zu regeln) kann man mit Processlasso auch die Taktraten des Processors regeln ? Ich hab da was von verschiedenen Takteinstellungen gesehen(stromsparen, multimedia etc.) aber nichts wo man explizit die Taktfrequenz einstellen kann. Im Prinzip sowas wie der CPU Governor unter Linux wo man für min,mid und max einen Takt vorgenen kann sowie die Reaktionszeit bei Lastveränderungen(um ständiges hoch und runtertakten bei kleinen laständerungen zu vermeiden).

Gruß Udo

[uli.brueggemann]

das Windows eigene Analysetool kenne ich auch, aber es ist aus meiner Sicht oversized für die Infos, die wir brauchen.

Was Dir helfen könnte bei Deinem Dropout-Problem wäre aus meiner Sicht das Tool Process-Lasso, mit dem Du Prozess-Prioritäten ändern kannst. Irgendein Prozess reißt alle Ressourcen an sich, sodass für den Audio-Prozess nicht mehr genug bleibt. Ich würde hier auch nicht das Problem beim Treiber sondern bei der Abspielsoftware suchen. Möglicherweise kommst Du schon zum Ziel, wenn Du deren Priorität ("hoch" oder "Echtzeit") erhöhst und die Automatische Thread-Priorität deaktivierst. Falls das nichts hilft, würde ich zusätzlich die Audioanwendungen auf einen Kern exklusiv zuteilen.

Hallo Fujak,

der DPC Latency Check zeigt die permanente DPC-Belastung des OHCI1394-Treibers seltsamerweise nicht an, da ist alles im grünen Bereich. LatencyMon hingegen zeigt ebenfalls richtig auf dass der Treiber um die 1 ms pendelt. Und xperf zeigt es wunderschön.

Der Treiber ist von Microsoft. Da kann ich nichts mehr tun. Habe aber nun auch festgestellt, dass der Firewire-Chipsatz von O2 Micro ist. Und da gibt es negative Rückmeldungen seitens RME. Bevorzugt/Empfohlen wird ein Chipsatz von Texas Instruments.

Das führt nun schlichtweg dazu, dass ich den Rechner nicht weiter verwenden will/kann. Werde es mal mit einem anderen Laptop testen, dort mit einer Firewire Expresscard und TI-Chips.

Grüsse
Uli

[mm2]

Hallo Fujak, hallo Uli,

bei Windows 8 haben Deine Ohren mal wieder gezeigt dass sie richtig liegen
Mit der Latency Fehlmessung hättest Du Dich und mich aber beinahe auf's Glatteis geschickt,
spätestens beim zeitlichen Verlauf der Latency wäre aber klar geworden, dass da
was nicht stimmen kann.

Was Dir helfen könnte bei Deinem Dropout-Problem wäre aus meiner Sicht das Tool Process-Lasso, mit dem Du Prozess-Prioritäten ändern kannst. Irgendein Prozess reißt alle Ressourcen an sich, sodass für den Audio-Prozess nicht mehr genug bleibt.

Ich hoffe Uli probiert es aus, oft ist es jedoch so, dass das System trotzdem nur ein paar % Systemlast zeigt.

Nach meinen Beobachtung kann man mit der „Prozess-Priorität“ beeinflussen wie oft ein Prozess zum Zug kommt. Mit dem Tool LatencyMon kann man sich ansehen wie oft ein Prozess ausgeführt wurde. Über die „Prozess-Priorität“ kann darauf Einfluß nehmen.

Aus meiner Sicht noch wichtiger ist die "highest execution time" ( wie oben schon mehrfach genannt ). Das scheint die Zeit zu sein die Prozess in Anspruch nimmt bis er sich vom Betriebssystem wieder unterbrechen läßt. Je nach dem wie viele Kerne man hat, kann das die Latency deutlich beeinflussen und auch zu Dropout-Problem führen.

Hat man einen oder mehrere Prozesse mit einer hohen „execution time" auf seinem System,
würde ich also eher davon ausgehen, dass man mit der „Prozess-Priorität“ wesentlichen Einfluß auf die Anzahl der Dropout-Problem hat, aber man sie damit nicht abstellen kann.

Ich würde hier auch nicht das Problem beim Treiber sondern bei der Abspielsoftware suchen. Möglicherweise kommst Du schon zum Ziel, wenn Du deren Priorität ("hoch" oder "Echtzeit") erhöhst und die Automatische Thread-Priorität deaktivierst.

Bin gespannt was Uli weiter berichtet, ich habe da doch den Treiber in verdacht.
Wenn es der „Firewire-Treiber“ wie bei Uli ist, über den die Audiodaten laufen
könnte dieser sogar benachteiligt wenn andere Prozesse als "hoch" oder "Echtzeit" laufen.

Was ist die „Automatische Thread-Priorität“ ?

@Uli verschiedene Treiber zu probieren wäre auch mein erster Ansatz gewesen.
Bei Grafiktreiber hilft es manchmal auch eine ältere Treiber Version zu versuchen
oder Du deaktivierst Firewire und versucht es über USB bevor Du einen anderen Laptop kaufst.

Viele Grüße

[Fujak]

Hallo Udo,

mir ist nicht ganz klar, weshalb Du nicht den CPU-Takt im Bios einstellst und dort auch die lastabhängige Takt-Automatik deaktivierst. So mache ich es jedenfalls. Mit ProcessLasso geht das leider nicht.

Grüße
Fujak

[Fujak]

Hallo Uli,

Das führt nun schlichtweg dazu, dass ich den Rechner nicht weiter verwenden will/kann. Werde es mal mit einem anderen Laptop testen, dort mit einer Firewire Expresscard und TI-Chips.

Das ist ja wirklich . Angesichts der Tatsache, dass Dein Notebook ja modern und technisch auf dem neuesten Stand ist, wäre es vielleicht günstiger, Dein Fireface 400 zu verkaufen und Dir ein Fireface UC zuzulegen, um genau diese Schwierigkeiten nicht mehr zu haben - zumal Firewire im Windows-Bereich eine aussterbende Schnittstelle ist.

Grüße
Fujak