Seite 5 von 22

Verfasst: 07.04.2014, 11:01
von Bernd Peter
Hallo,

es ist schon erstaunlich, wie anders der MQn-Player gegenüber JPlay zu Werke geht.

Es braucht einige Tage, bis das Gehör sich vollständig neu einpegelt.

Daß hier ein anderes Klangbild vorliegt, kein Problem, das merkt man sofort.

Das gesamte Potential kommt jedoch erst nach und nach zum Vorschein.

Eine gewisse Trägheit des Gehörsinns scheint hier mitzuspielen.

Gruß

Bernd Peter

Verfasst: 07.04.2014, 11:59
von khonfused
Bernd Peter hat geschrieben:Eine gewisse Trägheit des Gehörsinns scheint hier mitzuspielen.
Ich bin da auch ziemlich träge...

bekomme dafür aber nach dieser Aktion....
Bernd Peter hat geschrieben:Du kannst den Sack über den Kopf abnehmen und das Wasser aufwischen
ja bald den Friedensnobelpreis....

Verfasst: 07.04.2014, 14:34
von Fujak
Hallo Bernd Peter,
Bernd Peter hat geschrieben:es ist schon erstaunlich, wie anders der MQn-Player gegenüber JPlay zu Werke geht.
Es braucht einige Tage, bis das Gehör sich vollständig neu einpegelt.
das ging mir auch so. Schalte doch mal probeweise wieder auf JPlay, und lass Dich überraschen, wie jetzt Dein Gehör darauf reagiert....

Grüße
Fujak

P.S.: @Christian: Unser Hobby ist nichts für schwache Nerven, vor allem nicht, wenn Bernd Peter in der Nähe wohnt ... aber dafür den Friedensnobelpreis? Hm. :|

Verfasst: 07.04.2014, 17:46
von Aleg
Versuch mal die neue mqnplay 2.46 mit mqncontrol 1.3
Erstaunlich

:cheers:

Aleg

Verfasst: 07.04.2014, 18:07
von taggart
Aleg hat geschrieben:Versuch mal die neue mqnplay 2.46 mit mqncontrol 1.3
Erstaunlich
Hi Aleg,
2.46/2.47 mit 1.3 hatte ich heute morgen zum Frühstück - sehr lecker die Kombis! :cheers:
Gruß, Christoph

Verfasst: 07.04.2014, 19:25
von lukivision
Puuh - wie kriege ich denn Wasapi für MQN verfügbar? Ich hab bislang nur das Foobar WASAPI Plugin...

Luki

Verfasst: 07.04.2014, 19:46
von uli.brueggemann
Moin,

ich hab mal die

Code: Alles auswählen

mqncontrol.exe 24 bit R1.3 10ms.310ms
und

Code: Alles auswählen

mqnplay.exe 24 bit sse2 10ms R2.3 win7.3win7
genommen. Und mich zuerst mal nach der Anleitung von Christoph (http://www.aktives-hoeren.de/viewtopic. ... 274#p80274) gerichtet.

Was nach dem Aufruf der MQnControl zu folgenden Meldungen führt:
FEHLER - Zugriff verweigert

File format 16 bits per sample 44100 samples per second
File load count - 1
X -Exit:
Dann spielt die Musik aber trotzdem wie sie soll.

Nun frage ich mich, was die Zugriffsverweigerung verursacht. Kennt jemand den Grund?
Ich rufe dabei das Programm per cmd-Konsole im Verzeichnis C:\MQn auf.

Grüsse
Uli

Verfasst: 07.04.2014, 20:03
von uli.brueggemann
lukivision hat geschrieben:Puuh - wie kriege ich denn Wasapi für MQN verfügbar? Ich hab bislang nur das Foobar WASAPI Plugin...

Luki
Auf https://drive.google.com/folderview?id= ... sp=sharing gibt es auch ein Verzeichnis Test. Darunter gibt es eine WASAPI_test.exe.
Die listet mit
WASAPI_test.exe --list-devices die verfügbaren Devices auf.

Grüsse
Uli

Verfasst: 07.04.2014, 21:04
von lukivision
Uff- geschafft! Läuft mit der control und play exe von gestern, also vom 06.04. Jetzt erstmal Hören.
Danke Uli!

Luki

Verfasst: 07.04.2014, 21:22
von ESM
Hi Uli,
uli.brueggemann hat geschrieben:Moin,

Was nach dem Aufruf der MQnControl zu folgenden Meldungen führt:
FEHLER - Zugriff verweigert

File format 16 bits per sample 44100 samples per second
File load count - 1
X -Exit:
Dann spielt die Musik aber trotzdem wie sie soll.

Nun frage ich mich, was die Zugriffsverweigerung verursacht. Kennt jemand den Grund?
Ich rufe dabei das Programm per cmd-Konsole im Verzeichnis C:\MQn auf.

Grüsse
Uli
Wie man das bei normale Progrämmchen tut, startest Du vermutlich mit eingeschränkten Benutzerrechten. Der Player möchte gerne Vollzugriff auf dein System, also mit Adminrechten die Musik wiedergeben :mrgreen:

Gruß Erwin

Verfasst: 07.04.2014, 21:27
von Aleg
uli.brueggemann hat geschrieben:Moin,

ich hab mal die

Code: Alles auswählen

mqncontrol.exe 24 bit R1.3 10ms.310ms
und

Code: Alles auswählen

mqnplay.exe 24 bit sse2 10ms R2.3 win7.3win7
genommen. Und mich zuerst mal nach der Anleitung von Christoph (http://www.aktives-hoeren.de/viewtopic. ... 274#p80274) gerichtet.

Was nach dem Aufruf der MQnControl zu folgenden Meldungen führt:
FEHLER - Zugriff verweigert

File format 16 bits per sample 44100 samples per second
File load count - 1
X -Exit:
Dann spielt die Musik aber trotzdem wie sie soll.

Nun frage ich mich, was die Zugriffsverweigerung verursacht. Kennt jemand den Grund?
Ich rufe dabei das Programm per cmd-Konsole im Verzeichnis C:\MQn auf.

Grüsse
Uli
Uli

The program tries to change clockrate setting in the Pro Audio registry setting, but doesn't have sufficient rights to do so.

I have a batch that changes it again to clockrate 448, which is my favourite ( but not gordon's :mrgreen: ).

Cheers

Aleg

Verfasst: 08.04.2014, 08:57
von uli.brueggemann
Aleg hat geschrieben:The program tries to change clockrate setting in the Pro Audio registry setting, but doesn't have sufficient rights to do so.

I have a batch that changes it again to clockrate 448, which is my favourite ( but not gordon's :mrgreen: ).
Hi Aleg,

yes, I could trace it. MQn tries to create a new registry key HKLM\Software\Microsoft Windows NT\Current Version\Multimedia\SystemProfile\Tasks\Pro Audio
The access is denied correctly.

So what is the reason to write into the protected area and what is happening if the according registry key is NOT created? Does the playback get worse?

Clearly speaking I do not like to raise any privileges to programs of uncertain and uncertified sources.

Cheers
Uli

Verfasst: 08.04.2014, 12:28
von taggart
Hallo Uli,
der Registry-Zweig "HKLM\Software\Microsoft Windows NT\Current Version\Multimedia\SystemProfile" beinhaltet Werte, die für die Konfiguration des Multimediaklassenplaner-Dienstes (MMCSS) relevant sind. Dieser ermöglicht die Priorisierung verschiedener Mulitmedia-Anwendungen und -typen. Um diesen Dienst zu nutzen, muss sich eine Multimedia-Anwendung bei dem Dienst per API-Call registrieren.

Bezogen auf MQn passiert nun folgendes:
a. MQnControl.exe schreibt - je nach Audio Qualität (16/44.1, 24/96 etc.) der gerade gewählten Tracks - verschiedene Werte in den Eintrag "Clock Rate" im Zweig "HKLM\Software\Microsoft Windows NT\Current Version\Multimedia\SystemProfile\Tasks\Pro Audio". Welche Werte geschrieben hat Sbgk nach eigenen Überlegungen bestimmt.
b. MQnControl.exe startet MQnPlay.exe mit diversen Parametern und übergibt den PCM-Datenstrom.
c. MQnPlay.exe registriert sich per API-Call "AvSetMmThreadCharacteristics" mit Paramter "Pro Audio" beim MMCSS.
d. Die gesetzten Werte für "Clock Rate" sollten nun berücksichtigt werden

Soweit jedenfalls die Theorie!

Die Meinungen über die richtigen Werte für "Clock Rate" gehen auseinander. Der Standardwert dafür ist 10000 (Dezimal). Ich selbst habe in meiner Kette bei verschiedenen Werten keine Unterschiede wahrnehmen können. Allerdings habe damit auch noch nicht wirklich viel experimentiert.

Gruß, Christoph

Verfasst: 08.04.2014, 16:32
von Aleg
uli.brueggemann hat geschrieben:
Aleg hat geschrieben:The program tries to change clockrate setting in the Pro Audio registry setting, but doesn't have sufficient rights to do so.

I have a batch that changes it again to clockrate 448, which is my favourite ( but not gordon's :mrgreen: ).
Hi Aleg,

yes, I could trace it. MQn tries to create a new registry key HKLM\Software\Microsoft Windows NT\Current Version\Multimedia\SystemProfile\Tasks\Pro Audio
The access is denied correctly.

So what is the reason to write into the protected area and what is happening if the according registry key is NOT created? Does the playback get worse?

Clearly speaking I do not like to raise any privileges to programs of uncertain and uncertified sources.

Cheers
Uli
Uli

AS said my preference is a clockrate of 448, so after Gordon set his prefered value, I run a .reg file that puts it back to my prefered value :mrgreen:

The permissions can be changed on a pretty low level in the registry tree, so you could give regular users control permission (right mouse click / Permissions / Users allow Control) on
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile\Tasks\Pro Audio" only, which is where the clockrate setting for Pro Audio is located and no other areas will be affected. This solves the authorisation message.
If you want to be on the save side, you can also backup just this branch (right mouse click on this branch and select Export) that way you can always put it back the way it was.
In the history of MQn we have experimented with quite a lot of registry settings as well. JesusCheung on the Tirna Hifi thread is obsessed by them :shock: .

And Christoph, please do listen to clockrate 448 with the mqncontrol 100000 and mqnplay avx2 100000, it should give a noticeable difference to the default clockrate.

cheers and happy experimenting :cheers:

Aleg

Verfasst: 08.04.2014, 16:48
von uli.brueggemann
Aleg hat geschrieben: The permissions can be changed on a pretty low level in the registry tree, so you could give regular users control permission (right mouse click / Permissions / Users allow Control) on
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile\Tasks\Pro Audio" only, which is where the clockrate setting for Pro Audio is located and no other areas will be affected. This solves the authorisation message.

AS said my preference is a clockrate of 448, so after Gordon set his prefered value, I run a .reg file that puts it back to my prefered value :mrgreen:
Hi Aleg,

ok, changing the permissions for Pro Audio works well.
So MQn now changes the value from x2710 (=10000) to x27AF (=10159). Whatever this means.

Now I just wonder about your value of x448 (=1096). It is much lower. And you set it by a .reg file. You could set it and withdraw the permission to change it by MQn. Then you only need to set the value once. Am I wrong?

Cheers
Uli