Audioplayer MQn

[Bernd Peter]

Hallo Christian,

den 24/96 Test beim Veloce habe ich auch schon gemacht und kann deine Hörerfahrung nur bestätigen.

Allerdings will ich nicht ausschließen, daß das DSP-Preset in deinem Hörgerät falsch eingestellt ist.

Guck doch lieber mal nach.

Nette Grüße

Bernd Peter

[khonfused]

WAS??

Ich lass das auf der Hörgeräteakustikermesse am Wochenende mal überprüfen. Man darf nichts ausschließen.

[Bernd Peter]

Hallo Christian,

klingt interessant, ich komm dann auch, was gibt es zu essen?

Der Kaffee ist ja über alle Zweifel erhaben.

Gruß

Bernd Peter

[Fujak]

Hallo MQnler,

nachdem das mit dem Hörgeräteakustiker nun geklärt scheint, mal wieder zurück zum Tagesgeschäft, nämlich dem Durchhören der gefühlt 200 MQn-Versionen.

Aus meiner Sicht gehen die letzten Versionen in eine Richtung, die technisch gesehen möglicherweise richtig ist, sich unangenehmerweise klanglich aber wieder der Charakteristik von JPlay annähert. Die farbigen Mitten und der definierte und zugleich tiefreichende Bass aus früheren Versionen verschwindet zunehmend. Die letzte für mich sehr gut klingenede Version ist die 3.08 avx, doch schon das Pendant in der SSE2-Variante klingt zu scharf. Die letzte Version 3.11 avx finde ich ebenfalls zu scharf wenn auch noch nicht richtig digital.

Von den MQnControls finde ich die letzte Fassung in der 512-Variante am besten.

In ein paar Stunden wird sich Gordon wieder an die Arbeit machen. Ich bin gespannt, was uns dann erwarten wird.

Grüße
Fujak

P.S.: @Christoph: Dein MQnLoad ist ein wahrer Segen beim Durchtesten der einzelnen Versionen. Schade nur, dass Gordon immer wieder sein Namensgebungsschema ändert, sodass man händisch "nachbessern" muss. Aber es lohnt sich aus meiner Sicht auch nicht, wenn Du ihm in dieser schnellebigen Testphase mit Umprogrammierungen des MQnLoad nachläufst.

[Bernd Peter]

Na ja,

In ein paar Stunden wird sich Gordon wieder an die Arbeit machen.

warum muss der irgendwo rumhängen, wenn es was zu tun gibt?

Kennt jemand die Telefonnummer, ich ruf schon an.

Bernd Peter

[taggart]

Aber es lohnt sich aus meiner Sicht auch nicht, wenn Du ihm in dieser schnellebigen Testphase mit Umprogrammierungen des MQnLoad nachläufst.

Danke Fujak! Ich sehe das genauso und werde MQnLoad deshalb zunächst mal nicht weiter entwickeln (Bug-fixing ausgenommen). Die Dinge müssen sich erst einmal stabilisieren.

Gruß, Christoph

[lukivision]

Weil ich alleine nicht klar komme, frag ich mal hier: hab ein kleines Problem mit meinem DAC, nachdem ich auf MQn gewechselt bin: Der DAC (Eigenbau auf Basis Sabre ES 9018, Quartz ist TCXO 1ppm 80.000000MHz) produziert gelegentlich und unregelmäßig kleine Aussetzer (man hört für einen Augenblich nichts mehr und die blaue LED geht aus). Kennt das einer und hat vielleicht eine Lösung? Tritt nur bei MQn auf, bei foobar usw ist alles OK. Vielleicht sollte ich noch sagen, daß der DAC ein SPDIF Signal vom Fiio 10 Olympus bekommt.

Luki

[Bernd Peter]

Hallo,

die neue 3.14 finde ich rundum gelungen, interessanter ist jedoch die 3.18.

Mit der kann man sicher so manchen erst mal verblüffen, denn die ist wie unten beschrieben:

jesuscheung im Tir Na HiFi

3.18 may have highest quantity sum in resolution among all software i know on 2012
haven't detect major issue. natural sound is back.
strain is at lowest level since...
musicality/emotion can be better

Eine solche Raumentfaltung habe ich bei mir bisher noch nicht wahrgenommen, aber dem Klang fehlt etwas Kraft, Wärme und Energie.

Gruß

Bernd Peter

[Fujak]

Hallo Bernd Peter,

Verglichen mit der 3.14 avx finde ich die 3.18 sse2 zwar räumlicher aber in der Lokalisationsschärfe unpräziser, insbesondere die Phantommitte. Im Moment ist für mich die 3.14 avx die Referenz - im Moment, denn noch hat die nächste Arbeitsschicht von Gordon nicht begonnen ...

Grüße
Fujak

[Fujak]

Hallo Luki,

Der DAC (Eigenbau auf Basis Sabre ES 9018, Quartz ist TCXO 1ppm 80.000000MHz) produziert gelegentlich und unregelmäßig kleine Aussetzer (man hört für einen Augenblich nichts mehr und die blaue LED geht aus). Kennt das einer und hat vielleicht eine Lösung? Tritt nur bei MQn auf, bei foobar usw ist alles OK. Vielleicht sollte ich noch sagen, daß der DAC ein SPDIF Signal vom Fiio 10 Olympus bekommt.

Ich würde als erstes ein anderes SPDIF-Kabel ausprobieren. Falls das Problem weiter besteht, wäre es hilfreich, wenn Du noch weitere Informationen zu Deinem Setup von Fiio und Deinem DAC machen würdest.

Grüße
Fujak

[lukivision]

Hallo Fujak,

Danke für Deine Antwort. SPDIF-Kabel habe ich recht viele ausprobiert. Nicht bei allen war ich mir sicher, ob sie auch die 75Ohm einhalten. Ich habe auch verschiedene Längen (0,9m bis zu 15 m) ausprobiert, um evtl. Reflektionen zu kompensieren. An den Kabeln wird es nicht liegen. Der DAC ist dieser:

http://diyhifishop.com/upgrade-assemble ... p-193.html

Nicht auszuschließen, daß er nicht ganz sauber ausgelegt ist. Einzustellen gibt es da nichts. Dasselbe gilt auch für den Fiio E10 - auch da gibt es in dieser Hinsicht nichts einzustellen. Er wird von Windows 8.1 mit windows-eigenen Treibern versorgt und funktioniert. Ich verwende den Fiio als USB/SPDIF Wandler. Ich habe den Verdacht, daß er evtl. ein Quell des Übels ist - irgendwie kein ganz sauberes Signal weiterreicht. Die andere Möglichkeit wäre, daß der PC ein ungeeignetes Signal erzeugt. Wenn das so wäre - an welchen Schrauben kann ich drehen?

Luki

[Fujak]

Hallo Luki,

ich teile Deine Vermutung, dass die USB-SPDIF-Konvertierung im Fiio nicht ganz sauber ist. Im Hifi-Forum habe ich etwas dazu gefunden, wird dort "Spratzel-Problem" genannt (u.a. hier: http://www.hifi-forum.de/index.php?acti ... stID=51#51).

Da ja auch Dein DAC einen USB-Eingang hat, würde ich den mal testen, ob die Aussetzer dann immer noch auftreten.

Grüße
Fujak

[Fujak]

Hallo MQnler,

ich verfolge gerade auf Tirna-Hifi im MQn-Thread die Ausführungen von Aleg hinsichtlich der "clockrate 448". Hat das jemand von Euch schon klanglich ausprobiert? Aus meiner Sicht legt der Klang tatsächlich nochmal zu - die Versionen behalten zwar relativ zueinander ihren Klangcharakter, klingen aber insgesamt sauberer, straffer und musikalischer (also keineswegs steriler). Ich habe das vor allem im Vergleich der 3.14avx mit 3.18sse getestet.

Lästig ist allerdings, dass nach dem Start von MQnPlay.exe die Clockrate von Gordon eingestellt wird. Erst dann muss der Batchfile für die Clockrate gestartet werden.

@Christoph: Könnte man in die MQnLoad nicht einbauen, dass hier auf 448-clockrate.bat zugegriffen wird? Bzw. noch komfortabler, dass es in den Prefs von MQnLoad (Alt+Space) ein Fenster gibt, in welchem man die Clockrate eintragen kann. Dann könnte man mit verschiedenen Einstellungen seine bevorzugte Clockrate herausfinden.

Grüße
Fujak

[taggart]

@Christoph: Könnte man in die MQnLoad nicht einbauen, dass hier auf 448-clockrate.bat zugegriffen wird? Bzw. noch komfortabler, dass es in den Prefs von MQnLoad (Alt+Space) ein Fenster gibt, in welchem man die Clockrate eintragen kann. Dann könnte man mit verschiedenen Einstellungen seine bevorzugte Clockrate herausfinden.

Hallo Fujak,

die Diskussionen bezüglich der Clockrate werden im Tir-Forum schon länger geführt. Letztlich hat sich keine Übereinstimmung bei den Werten ergeben. Verschiedene User bevorzugten verschiedene Werte. Zudem bezweifle ich, dass die Korrektur über eine Batch nach dem Start von mqnplay funktioniert - und zwar aus folgendem Grund:

Die Einstellungen im Pro Audio Zweig der Registry sind nur für den Multimediaklassenplaner Dienst (MMCSS) relevant. Eine Audio-Applikation wie mqnplay.exe kann diese Werte nicht direkt verwenden, sondern muss sich selbst aktiv beim MMCSS Dienst registrieren. Das geht per API Call (AvSetMmMaxThreadCharacteristics oder AvSetMmThreadCharacteristics). Durch die Registrierung stellt sich die Audio-Anwendung quasi unter die Kontrolle des MMCSS und nur dann kommen auch die in der Registry eingestellen Werte zum Tragen. Näheres dazu hier:

http://msdn.microsoft.com/en-us/library ... s.85).aspx

Gordon nimmt diese Registrierung beim Start der mqnplay.exe auch tatsächlich vor. Zweifel bestehen nun darin, ob sich eine anschließende Änderung der Registry-Werte überhaupt noch auswirken kann, denn dafür müsste der MMCSS Dienst diese ständig kontrollieren und die Änderungen berücksichtigen. Für wahrscheinlicher halte ich, dass die Werte der Registry nur zum Zeitpunkt der Registrierung einer Audio-Anwendung beim MMCSS gelesen und dann fest verwendet werden. Eine verlässliche Aussage dazu konnte ich bisher jedoch nirgends finden. Wenn das aber so stimmt, dann würde weder Aleg's Batch noch eine nachgeschaltetes Eingreifen durch MQnLoad irgendwas bewirken können und letztlich würde man eine mqncontrol.exe von Gordon brauchen, die einstellbare Werte für die Clockrate aus einer Config-Datei liest. Nur das wäre wirklich verlässlich, da dann die Werte vor der Registrierung der mqnplay.exe beim MMCSS aus der Config-Datei gelesen und in die Registry geschrieben werden könnten.

Gruß, Christoph

[Aleg]

The only thing is the info in the link says about Clock Rate:

A hint used by MMCSS to determine the granularity of processor resource scheduling.

So I interpret this as that this setting is used by the MMCSS itself and not meant to be used by the threads it manages.

Also several people do notice a difference by applying it.



Aleg