Audioplayer MQn

[ESM]

Hallo Aleg, Fujak und Christoph,

es gibt verschiedene Quellen. Eine ganz einfache ist es, zu sniffen.

Aleg war schon ganz nah dran. Mark Russinovich hat zwar nicht alles dokumentiert was Windows so macht, aber er stellt Werkzeuge bereit, mit denen sich das ermitteln lässt.



dieser Filter macht erstmal Sinn:



hier ein Trace:



Durch den Filter sieht man nur die Zugriffe lesend und schreibend auf die Parameter Clock Rate. Die ersten 8 Zeilen lesend erfolgen während ich den Dienst MMCSS (über den Loader svchost) starte. Das ist also die Ausgangssituation.

Dann kommt 3 mal ein Doppel durch reg.exe lesend und schreiben. Lesen passiert automatisch immer, bevor man schreibt. reg.exe wird von MQnControl.exe benutzt, um den Wert in die Registry zu schreiben. Es folgen noch 2 Doppel durch reg.exe, da ich MQnControl zum testen 2 mal beendet und 2 mal neu gestartet habe.

Wie man sieht, wird der gesetzte Wert anschließend nicht mehr von System (Dienst) gelesen, damit kann sich klanglich auch nichts ändern.

Startet man den Dienst neu, wird der Wert neu eingelesen und "könnte" verwendet werden (hab ich hier aber nicht noch mal mit aufgezeichnet).

Ohne Filter seht ihr alles was im System sonst noch so passiert. Z.B. wann MQnControl über cmd gestartet wird, wann mqnplay übernimmt, und und und. Allerdings ist es ohne geschickte Filter schwer das Relevante zu finden. 1 Mio und manchmal mehr Ereignisse innerhalb kurzer Zeit sind normal. Trotz des scheinbaren Stress funktioniert die Audiowiedergabe doch erstaunlich gut. Vielleicht aber auch gerade weil im System so viel miteinander kommuniziert wird.

Gruß Erwin

[Fujak]

Hallo Erwin,

besten Dank für diese Dokumentation. Das schaut sehr aufschlussreich aus. Ich werde das mal am WE auf meinem Rechner nachvollziehen.

Grüße
Fujak

[Aleg]

Also, was ich dann allerdings erreicht habe mit mein clockrate448.bat ist das immer meine 448 werte als letzte geschrieben in Registry wird und also auch immer die werte ist mit dem mein PC gestartet wird und nicht mit der Werte die vom MQNControl geschrieben wird.

Also doch Wertvoll, zwar nicht sofort aber denn sicher nach Reboot
Auch finde ich meine 448 Werte besser klingen dann die Werte von Mqncontrol


Aleg

[taggart]

Christoph

Es wäre besser als mqnplay sein eigene ungeteilte Core hat.
Mqncontrol darf bei den sonstigen prozessen hinzugefügt werden. Mqncontrol ist nicht so wichtig aber mqnplay soll ein ungeteilte core haben und ich meine auch das Realtime für MQnPlay besser ist.

Versuchs mal!



Aleg

Hi Aleg,
ich meine, ich hatte das auch so wie du es vorschlägst schon mal - werde es morgen aber nochmal testen. Danke.
Gruß, Christoph

[taggart]

Hallo Erwin,
damit wäre diese Frage dann ja nun auch geklärt. Sehr schön!
Das Stoppen und Starten des MMCSS macht in der mqncontrol.exe jedoch nur wenig Sinn. Es dauert zu lange und muss eh nur selten gemacht werden. Besser wäre m.M.n., Gordon lässt es ganz raus und MQnLoad macht dies über die GUI möglich.
Gruß, Christoph

[ESM]

Hallo Christoph,

Das ist in der Tat die beste Idee für den Zweck.

Gruß Erwin

[nightingale]

Ich habe nach tasker gegoogelt, aber nicht das richtige Tool gefunden. Kann bitte jemand einen download link einstellen. Danke!

[Aleg]

Ich habe nach tasker gegoogelt, aber nicht das richtige Tool gefunden. Kann bitte jemand einen download link einstellen. Danke!

Peter

Hier findest du ein link von Christoph: http://www.tirnahifi.org/forum/viewtopi ... 794#p51794

[Bernd Peter]

Hallo,

so, jetzt zwäng ich mich mal zwischen die Computeräxberden.

Wenn ich es richtig verstehe, ist dieser neue Wert 448 für den Dienst MMCSS beim Computerstart wichtig.

Steht er beim Start in der Registry unter Clockrate bei

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile\Tasks\Pro Audio

dann passt es, auch wenn durch das anschließende Starten von MQn die control.exe den Wert mit 10159 wieder überschreibt. Macht nichts, Hauptsache MSCC läuft mit 448, weil es diesen Wert nur einmal, eben beim Windowsstart ausliest (so hat es Erwin uns nachgewiesen).

Vor Ausschalten bzw. Neustart des PC muss man nun über einen Registrierungsbefehl (reg.exe) die 448 erneut eingeben oder Alegs clockrate448.bat verwenden, sonst würde die MMCSS beim nächsten Start die 10159 einlesen und das war es dann für diese Windowssession.

Das könnte man auch einfacher haben, dazu müsste Gordon aber die control.exe anpassen.

Hoffe, ich hab es richtig verstanden, Christoph.

Gruß

Bernd Peter

[nightingale]

Peter
Hier findest du ein link von Christoph: http://www.tirnahifi.org/forum/viewtopi ... 794#p51794

Danke Aleg

[taggart]

Hallo,
nun dachten wir ja, dass Erwins Tests mit den SysInternal Tools klar belegen, dass der MMCSS Dienst die Registriy-Werte für Pro Audio nur beim Start einliest.

Im Tir-Forum gibt's aber User, die definitiv davon überzeugt sind, dass z.B. der Wert für die Clock Rate bei jeder Änderung gelesen wird. Da sich dieses erneute Lesen nicht im Process Monitor zeigt, wird hier vermutet, dass entweder ein Zeiger auf diesen Wert vom MMCSS verwendet wird oder aber sich der Dienst für Werte-Änderungen an der Registry über einen API-Call registriert - der MMCSS also von der Registry bzw. dem System informiert wird, wenn Änderungen an diesem Werte auftreten.

Das erste kann ich mir nicht wirklich vorstellen, da die Registry eine Datenbank ist und mir keine Mechanismus für Zeiger auf Datenbank-Werte bekannt ist. Letzteres klingt jedoch durchaus so, als könne dies möglich sein.
Ich habe echt keine Ahnung mehr, was tatsächlich gilt - Erwin, hast du eine Meinung dazu? Oder sonst jemand? Ich hätte das ja gern zweifelsfrei geklärt ...

Gruß, Christoph

[ESM]

Hallo Christoph,

vermutlich möchte man das glauben. Kennt sich jemand wirklich damit aus?

Jeder Zugriff eines jeden Programms auf die Registry erfolgt über ein API Call. Das hat erst mal nichts mit Zeigern zu tun. Wissen die Leute was Zeiger sind und wann sie zum Einsatz kommen und warum sie zum Einsatz kommen?

Selbst der Service MMCSS macht sich dieser vorhandenden API zunutze um den Wert zu lesen. Und das tut er immer wieder, wenn er den Wert (von dieser Stelle) braucht.

C++
LONG WINAPI RegQueryValueEx(
_In_ HKEY hKey,
_In_opt_ LPCTSTR lpValueName,
_Reserved_ LPDWORD lpReserved,
_Out_opt_ LPDWORD lpType,
_Out_opt_ LPBYTE lpData,
_Inout_opt_ LPDWORD lpcbData
);

Es gibt Bibliotheken die den Zugriff noch mal kapseln, also vereinfachen um mit abstrakteren Programmiersprachen darauf zugreifen zu können (Delphi, Visual Basic, C#, ...). Letztendlich wird aber diese API wieder nativ aufgerufen, um an den Wert zu kommen.

Es gibt nur eine andere Möglichkeit, nicht mit dem Wert aus der Registry innerhalb des Dienstes zu arbeiten.
Dazu muss das API von MMCSS eine Funktion bereitstellen, in der das aufrufende Programm (z.B. mqn) einen vom Default (z.B. aus Registry) abweichenden Wert für z.B. Clock Rate entgegen nehmen kann, um diesen zur Laufzeit abweichendvom Eintrag in der registry zu anzuwenden. Dann muss der Wert in der Registry aber nicht mal geschrieben stehen;-)

Aber ich bin auch nicht allwissend und lerne gerne dazu. Wenn jemand aber glaubt und Halbwissen hat reicht das doch nicht. Das sind immer diese Dinge, die dann erstmal geheimnisvoll im Raum stehen, immer wieder geschrieben und verbreitet werden bis sie dann irgendwann als Fakt angesehen werden um dann für Klangsteigerungen zu sorgen.

was ich komisch finde ist, dass bis zuletzt nichtmal jemand wusste, wann der Wert überhaupt aus der Registry gelesen werden.

Gruß Erwin

[taggart]

Hallo Erwin,

Hallo Christoph,
vermutlich möchte man das glauben. Kennt sich jemand wirklich damit aus?

Einige der Jungs im Tir-Forum sind schon ganz gut in Windows unterwegs. Was aber mögliche Erklärungen betrifft, so werden diese im Moment eher als Vermutungen geäußert, denn als Überzeugung mit konkreter Begründung.

Jeder Zugriff eines jeden Programms auf die Registry erfolgt über ein API Call. Das hat erst mal nichts mit Zeigern zu tun.

Sehe ich genauso.

Wissen die Leute was Zeiger sind und wann sie zum Einsatz kommen und warum sie zum Einsatz kommen?

Das würde ich annehmen, auch wenn es in diesem konkreten Fall m.M.n. nicht wirklich passt.

Selbst der Service MMCSS macht sich dieser vorhandenden API zunutze um den Wert zu lesen. Und das tut er immer wieder, wenn er den Wert (von dieser Stelle) braucht.
C++
LONG WINAPI RegQueryValueEx(
_In_ HKEY hKey,
_In_opt_ LPCTSTR lpValueName,
_Reserved_ LPDWORD lpReserved,
_Out_opt_ LPDWORD lpType,
_Out_opt_ LPBYTE lpData,
_Inout_opt_ LPDWORD lpcbData
);

Richtig, das wäre der Standard und diese Zugriffe sind ja im Prozess Monitor auch sichtbar. Die Frage ist aber, ob's nicht anders auch funktioniert und die Zugriffe dann über diesen alternativen Weg nicht sichtbar sind.

Es gibt nur eine andere Möglichkeit, nicht mit dem Wert aus der Registry innerhalb des Dienstes zu arbeiten.
Dazu muss das API von MMCSS eine Funktion bereitstellen, in der das aufrufende Programm (z.B. mqn) einen vom Default (z.B. aus Registry) abweichenden Wert für z.B. Clock Rate entgegen nehmen kann, um diesen zur Laufzeit abweichendvom Eintrag in der registry zu anzuwenden. Dann muss der Wert in der Registry aber nicht mal geschrieben stehen;-)

Naja, es gibt noch dieses hier:
http://msdn.microsoft.com/en-us/library ... 85%29.aspx
Habe mich damit noch nicht wirklich auseinandergesetzt, ganz von der Hand zu weisen ist das aber nicht. Das aufrufende Programm (hier also der MMCSS) registriert sich für die Überwachung eines Wertes und wird benachrichtigt, wenn sich dieser Wert ändert. Klingt für mich erstmal möglich.

Aber ich bin auch nicht allwissend und lerne gerne dazu.

Wer ist das schon. Und das ist ja das schöne an der Internet-Community - oft wissen andere, was man selbst noch nicht weiß.

was ich komisch finde ist, dass bis zuletzt nichtmal jemand wusste, wann der Wert überhaupt aus der Registry gelesen werden.

So komisch finde ich das nicht. Das Thema ist ja überhaupt eines geworden, weil einige Leute sehr überzeugt davon waren, das dieser Wert den Klang on-the-fly ändert. Ich selbst konnte zwar nie Klangänderungen durch die Änderung der Clock Rate wahrnehmen, wer aber nun richtig liegt ist immer noch nicht abschließend geklärt. Entweder denken einige nur, dass es Änderungen gibt, oder ich habe keine guten Ohren oder eine Kette, die diese Änderungen nicht transportiert. Beides ist möglich.

Gruß, Christoph

[Aleg]

Auf TirNa Forum wird diese Funktion vorgeschlages die es möglich machen könnte ohne lesen die neue Werte zu bekommen: RegNotifyChangeKeyValue http://msdn.microsoft.com/en-us/library ... 85%29.aspx

Wäre so etwas möglich ohne diese Registry Zugang im ProcesMonitor zu sehen?

[taggart]

Hi Aleg,
genau das ist die Frage! Ich habe keine Ahnung, vermutlich müsste man es selbst probieren und ein Test-Programm schreiben.

Gruß, Christoph