Audioplayer JPlay

[ESM]

Hallo Alex,

ich kann auch nichts Auffälliges erkennen. Evtl. haben die Experten ein besseres Auge dafür. Meldet bei dir der LatencyMon während der Wiedergabe inkl. jPlay und Acourate Convolver dopouts? Wie sieht es bei der Wiedergabe ohne jPlay/ohne Acourate aus?

Gruß Erwin

[Jahresprogramm]

Hallo Erwin,

es läuft doch nun alles bestens. Was der ASIO Puffer mit dem JPlay, welcher bei mir über KS die Daten an die Soundkarte weitergibt, zu tun hat, ist für mich zwar nicht verständlich, aber es läuft.

Grüße
Alex

[cantusfirmus]

Werte JPlayer,

ich beantworte meine Frage selbst:

Die Häckchen bei den Asio Settings in Foobar
- Use 64-bit ASIO drivers und
- Run with high process priority

gehören entfernt. Dann findet foobar auch den JPlay Driver, der ausgewählt werden kann.

Grüße Horst

[ESM]

Hi Alex,

ok, dass ist ja toll. Hatte ich oben wohl nicht richtig verstanden, dass es jetzt geht. Was den ASIO Puffer angeht, vermute ich folgendes: Der Convolver hängt da ja dran. Wenn der Convolver durch jPlay gebremst wird könnte ich mir vorstellen, dass der AC die Daten aus dem Puffer nicht schnell genug abholen kann und der Puffer dann in Bruchteilen von Sekunden nicht mehr die richtigen Daten enthält. Uli hat sicher eine fundiertere Erklärung.

Gruß Erwin

[uli.brueggemann]

Wenn der Convolver durch jPlay gebremst wird könnte ich mir vorstellen, dass der AC die Daten aus dem Puffer nicht schnell genug abholen kann und der Puffer dann in Bruchteilen von Sekunden nicht mehr die richtigen Daten enthält.

Zu kleine Puffer bedeuten schlichtweg eien häufigeren Zugriff und damit Wettbewerb zwischen Prozessen. Wenn der Wettbewerb dabei nicht fair ist, bleibt klar mindestens ein Prozess auf der Strecke. Wenn das gerade derjenige ist, welcher sich hörbar bemerkbar macht, dann ist es eben drastisch auffallend.
Bei größeren Puffern bleibt dann noch eine gewisse Reserve, weil es eben länger dauert bis der Puffer leer ist.

Grüsse
Uli

[Fujak]

Hallo JPlayer,

die Diskussion über den AcourateConvolver macht m.E. auf einen Umstand aufmerksam, der bei JPlay Markenzeichen ist: JPlay setzt kompromisslos auf Klangqualität durch "sauberstmögliche" Signalaufbereitung - alles andere tritt dem gegenüber zurück.

Wer die bisherige Entwicklung der Software-Versionen verfolgt und am eigenen Setup klanglich nachvollzogen hat, kann erkennen, dass Usability (GUI und Einbindung weiterer Software-Komponenten) nur insoweit realisiert wurde, wie es die Klangqualität nicht beeinträchtigt. Das ist nun mal das Konzept, und es nützt wenig, sich über JPlay zu beklagen oder im Zusammenhang mit Prozessprioritäten gar von unfairem Wettbewerb zu sprechen. Wer mehr Usability und Flexibilität möchte, muss vorerst auf andere Player ausweichen oder bei JPlay gewisse klangliche Kompromisse eingehen.

Zu diesen klanglichen Kompromissen rechne ich übrigens auch das Online-Convolven insgesamt. Es bietet zwar eine bessere Usability - gerade in Bezug auf die "Vorratsdatenspeicherung", aber wenn man sich die Mühe macht, Online- und Offline-Faltung im direkten Hörvergleich zu testen, wird man feststellen, welche Methode mehr Details, mehr Räumlichkeit und mehr Ruhe im Klangbild beinhaltet.

Jeder muss da für sich persönlich abwägen, was ihm wichtiger ist.

Grüße
Fujak

[Jahresprogramm]

Hallo Fujak,

fair oder unfair ist sehr dehnbar. Darauf will ich nicht rumhacken. Denn falls JPlay tatsächlich die Energiekonfiguration meines Win8 bei der Installation auf Höchste-Performance setzt, fühle ich mich auch unfair behandelt. Ich will nämlich eher Strom sparen - meinen Kindern zu Liebe

Das hat mit JPlay oder deren Markenzeichen eher weniger zu tun, sondern eher mit meinem Verständnis der Prioritäten.

Grüße
Alex

[uli.brueggemann]

Das ist nun mal das Konzept, und es nützt wenig, sich über JPlay zu beklagen oder im Zusammenhang mit Prozessprioritäten gar von unfairem Wettbewerb zu sprechen.

Fujak,

darf ich darauf hinweisen, dass ich die Begriffe 'fair scheduling' oder 'race condition' schlichtweg als neutral ansehe? Es geht hier doch um eine sachliche Klärung über Vorgänge und Prozessabläufe. Das hat nichts damit zu tun, dass einer dem anderen weh tun und sich der andere nun beklagen muss.

Es sollte klar ein, dass wenn ein Treiber
- sauber programmiert ist
- und als einziger Treiber läuft bzw. Echtzeitprio hat,

dies die beste Bedingung ist. Da braucht es auch keine ominösen Registry-Settings etc., das wären dann nur die Versuche, die Programmierung sauber und effizient zu bekommen.

Wenn es aber ein Multitasking-System ist, dann sind nun einmal Prioritäten zu verteilen. Es stehen die Prozesse im Wettbewerb. Und wenn sich dabei ein Prozess alle Prioritäten nimmt, sind nicht notwendigerweise die anderen Prozesse schuld (oder schlecht programmiert), denen eben evtl. nötige Rechenzeit entzogen wird.

Ich gehe z.B. davon aus, dass JPlay gar nichts davon weiss (noch nicht mal auf die Idee kommt), dass die Audiodaten dahinter nochmals behandelt werden (im Fall AcourateConvolver). Ich gehe aber auch davon aus, dass die Jungs ansonsten wissen, dass sie mit realtime-Prioritäten höllisch vorsichtig sein müssen. Schliesslich weist praktisch jede Doku auf die Gefahren hin.

Process that has the highest possible priority. The threads of the process preempt the threads of all other processes, including operating system processes performing important tasks. For example, a real-time process that executes for more than a very brief interval can cause disk caches not to flush or cause the mouse to be unresponsive.

If a thread runs at the highest priority level for extended periods, other threads in the system will not get processor time. If several threads are set at high priority at the same time, the threads lose their effectiveness. The high-priority class should be reserved for threads that must respond to time-critical events. If your application performs one task that requires the high-priority class while the rest of its tasks are normal priority, use SetPriorityClass to raise the priority class of the application temporarily; then reduce it after the time-critical task has been completed. Another strategy is to create a high-priority process that has all of its threads blocked most of the time, awakening threads only when critical tasks are needed. The important point is that a high-priority thread should execute for a brief time, and only when it has time-critical work to perform.

You should almost never use REALTIME_PRIORITY_CLASS, because this interrupts system threads that manage mouse input, keyboard input, and background disk flushing. This class can be appropriate for applications that "talk" directly to hardware or that perform brief tasks that should have limited interruptions.

Insofern sehe ich die diversen Betaversionen von JPlay übrigens als begrüßenswerten Ansatz, im Wettstreit zwischen den Prozessen zu einer möglichst optimalen Lösung zu kommen.Was manchmal auch nur durch 'trial and error' geht. Es kann ja nicht vorausgesetzt werden, dass jeder Anwender eine 'pure dedicated audio engine' verwendet.

Grüsse
Uli

[Rabl]

Denn falls JPlay tatsächlich die Energiekonfiguration meines Win8 bei der Installation auf Höchste-Performance setzt, fühle ich mich auch unfair behandelt. Ich will nämlich eher Strom sparen

Hallo Alex,

darüber habe ich mich auch gewundert und ich habe kurzerhand das Energieschema "Höchste Performance" so angepasst, dass es wieder Strom spart. Einen Klangunterschied habe ich dadurch nicht feststellen können, aber der Lüfter hat aufgehört dauernd zu laufen, was sich klanglich sehr positiv bemerkbar gemacht hat.

Allerdings betreibe ich auch nur die 1 PC Variante. Eventuell hat das im 2 PC Betrieb oder in einem anderen Setup doch Einfluss auf die Wiedergabe.

Viele Grüße,
Rainer

[Jahresprogramm]

Hallo Rainer,

Einen Klangunterschied habe ich dadurch nicht feststellen können, aber der Lüfter hat aufgehört dauernd zu laufen, was sich klanglich sehr positiv bemerkbar gemacht hat .

Ob die Energiesparoptionen auf die seitens JPlay offensichtlich benötigte Real-Time Prio. Einfluss haben könnten, kann man, wenn auch nur oberflächlich, mit dem "DPC Latency Checker" überprüfen. Ich habe bei meinem AMD-System keinerlei Auswirkungen auf die Latenzen bei beliebigen Werten (0-100% Minimaler Leistungszustand) in der Prozessorenergieverwaltung feststellen können. Anders hat es bei anderen und des öfteren bei Intel-Systemen ausgeschaut.

Zum Überprüfen einfach den DPC Latency Checker runterladen und starten. Anschließend die o.g. Werte in der Prozessorenergieverwaltung verändern, bestätigen und schauen ob das irgendwelche Auswirkungen auf die Latenzzeiten hat. Wenn nicht, kann man m.E. getrost auf die Energiesparplan-Ausbalanciert zurückgreifen.

Grüße
Alex

[ESM]

Hallo Fujak,

Zu diesen klanglichen Kompromissen rechne ich übrigens auch das Online-Convolven insgesamt. Es bietet zwar eine bessere Usability - gerade in Bezug auf die "Vorratsdatenspeicherung", aber wenn man sich die Mühe macht, Online- und Offline-Faltung im direkten Hörvergleich zu testen, wird man feststellen, welche Methode mehr Details, mehr Räumlichkeit und mehr Ruhe im Klangbild beinhaltet.

da ich jemand bin (wie wohl die meisten, die sich ausgerechnet hier diesem Forum angemeldet haben), der mit den eingesetzten Mitteln das Optimum an Klang rausholen möchte, wäre ich für einen Tip dankbar, wie ich die Offline-Methode testen kann. Meinetwegen für diesen Test ohne Acourate Flow, da ich AcourateNAS zur Zeit noch nicht besitze.

Gibt es hierzu einen frei verfügbaren , kostenlosten Falter, der Musikfiles mit den acourate Filtern ohne Abstriche falten und abspeichern kann? Geht das offlinefalten auch Mehrkanal, also mit Weichenfunktion über mehrere Chassis? Über einen Link würde ich mich freuen.

In Verbindung mit dem Online-Convolving ist für mich mit JPlay aktuell kein wesentlicher Mehrwert erkennbar/hörbar. Zwischenzeitlich war ich mal recht sicher, evtl. aber etwas zu euphorisch. Nachdem ich dann mal Tests mit exaktem Pegelabgleich durchgeführt hatte, hat sich die Euporie etwas gelegt. Evtl. hast Du ja Recht und es gilt tatsächlich und leider das Highlander Prinzip (entweder online falten, oder JPlay mit offline gefalteten Musikdateien)

Gruß Erwin

[Fujak]

Hallo Erwin,

ich führe das Offline-Falten mit Foobar (neueste Version) durch. Hierzu braucht es die foo_convolve.dll-Erweiterung von der Foobar-Site, die in den Ordner "components" abgelegt wird.

Mit rechtem Mausklick auf die Datei oder das Verzeichnis geht man zu "Convert" und kann hier mit den Einstellungen den Convolver aktivieren. Danach werden die Musikdateien in das vorbestimmte Verzeichnis gefaltet. Die originalen Dateien bleiben dabei unangetastet.

Grüße
Fujak

[nightingale]

Ich habe eben die aktuelle JPLAY Version 5 RC8h getestet. Ich kann keine Änderung der SQ feststellen, jedoch läuft sie in meinem Setup nun stabil. Speziell beim Ändern der samplerate hatte mein System noch Probleme mit RC8f in Kombination mit der RME FF400. Ausserdem bei mir nun noch kleinere Werte für die JPLAY buffersize möglich.

LG
Peter

[nightingale]

Gibt es eine Möglichkeit in einem JPLAY setup die samplerate automatisch umschalten zu lassen? Ich verwende foobar2000 als GUI.

[Fujak]

Hallo Peter,

Deine Rückmeldung bezüglich RC8h entspricht auch meinem Eindruck: SQ auf einem unverändert hohen Niveau bei gleichzeitig größerer Stabilität. Ich hatte mit den Vorgängerversionen im Dual-PC-Setup immer das Problem, dass 24/192-Dateien nur etwas länger als eine Minute liefen (Du hast das sicher im JP-Forum mitverfolgt), nun aber laufen sie die volle Länge einwandfrei.

Zu Deiner Frage bezüglich der Umschaltung der Samplerate: Meinst Du das Umschalten im Fireface (Firewire oder SPDIF)? Denn ansonsten schaltet JPlay ja automatisch die Samplerate um - jedenfalls kann ich das im Display meines Big Ben erkennen.

Grüße
Fujak