Hallo Maximilian, hallo Ulli,
wegen der Kompatibilität zu den meisten gängigen Playern, die Asio "verstehen" nutzt JPlay diese Schnittstelle, um sich in den Player "einnisten" zu können. Es bedeutet aber nicht, dass JPlay dadurch über Asio wiedergibt. Welche Ausgabe dann letztlich angesprochen wird, kann man dann in den JPlay-Settings einstellen. JPlay kann mittlerweile über DS, WASAPI, ASIO und KS wiedergeben.
Wenn das adressierte Device einen Asio-Treiber vorsieht (meistens dann, wenn über USB connectiert wird), dann sollte man das nach meinen Erfahrungen nutzen, da hierdurch meistens erst die volle Funktionalität und Klanggüte gewährleistet wird.
@Maximilian: Bei unserem Treffen bei mir hatten wir ja die klangliche Überlegenheit der USB-Schnittstelle Deines Asus-DAC gegenüber SPDIF deutlich hören können. Damit das dafür verantwortliche asynchrone Übertragungsprotokoll ordnungsgemäß funktioniert, braucht es den firmeneigenen USB-Treiber, der in dem Falle über ASIO läuft. Der müsste dann auch in den Settings von JPlay (also nicht vom Player, der als GUI fungiert) eingestellt werden.
Eine generelle klangliche Überlegenheit von ASIO gegenüber KS (wie auch umgekehrt) leitet sich m.E. dadurch aber nicht ab. Auch WASAPI kann klanglich ebenbürtig sein, bedeutet in den Systemeinstellungen aber einen erhöhten Konfigurationsaufwand.
Grüße
Fujak
Audioplayer JPlay
Hallo Uli, hallo Fujak,
Habt Ihr Info wann jplay V5 verfügbar sein wird?
Viele Grüße
Maximilian
danke für die Ergänzung, ja genau so war es gemeint.modmix hat geschrieben: Unter v5 wäre dann wohl die Frage, wie sich ASIO/KS und ASIO/ASIO unterscheiden...
wie von Dir beschrieben, sollte man dabei berücksichtigen, dass man dabei ggf. ASIO mit asynchronen Übertragungsprotokoll gegen DS, WASAPI, KS mit synchronen Übertragungsprotokoll vergleicht. Dass dabei ASIO mit asynchronen Übertragungsprotokoll im Vorteil ist, dürfte klar sein. Ich will beim Asus nicht auf den asynchronen Übertragungsmodus verzichten, das bedeutet den ASIO Treiber zu verwenden.Fujak hat geschrieben:Damit das dafür verantwortliche asynchrone Übertragungsprotokoll ordnungsgemäß funktioniert, braucht es den firmeneigenen USB-Treiber, der in dem Falle über ASIO läuft. Der müsste dann auch in den Settings von JPlay (also nicht vom Player, der als GUI fungiert) eingestellt werden.
Habt Ihr Info wann jplay V5 verfügbar sein wird?
Viele Grüße
Maximilian
-
uli.brueggemann
- Aktiver Hersteller
- Beiträge: 4672
- Registriert: 23.03.2009, 15:58
- Wohnort: 33649
- Kontaktdaten:
Moderativer Hinweis: Dieser Beitrag wurde aus dem Thread Audio-PC für JPlay - welche Zutaten? herausgenommen, da mir das Thema und eine mögliche sich daran anschließende Diskussion hier besser aufgehoben scheint.
Grüße Fujak
_______________________________________________________________________________________________________
Mir fallen zu diesem Thema ein paar Gedanken ein, einfach mal ungeordnet aufgelistet:
Eine übliche Konfiguration mit JPlay wird wohl sein:
Player (z.B. Foobar) -> JPlay -> Soundkartentreiber (z.B. Asio)
Der Sinn von JPlay scheint mir hier zu sein, dass die Aufbereitung des Datenstroms für den Treiber (welcher immer an letzter Stelle kommt !) gleichmässiger wird. Dazu baut JPlay wohl einen entsprechenden Puffer auf und schraubt sich die Priorität entsprechend hoch.
Mit AcourateConvolver wäre die Kette dann so:
Player -> Jplay -> AcourateConvolver -> ASIO-Treiber
AcourateConvolver reagiert eventgesteuert auf den ASIO-Treiber und gibt zum einen Daten an den ASIO-Ausgangspuffer aus (festgelegt über die Soundkarte, üblicherweise 1024 bis 2048 Bytes/Kanal, keinesfalls 200 MB !). Zum anderen sammelt AC die Eingangsdaten (Puffergröße ebenfalls 1024 bis 2048 Bytes/Kanal) solange, bis ein für die Rechenlast günstiger Sammelpuffer (Größe = FFT-Partition) vorliegt.
Innerhalb des Prozesses sind die Prioritäten sauber gestuft, in absteigender Reihenfolge wären das: ASIO-Treiber -> Buffer Eventswitch -> Convolution -> GUI.
Ich sehe hier eigentich überhaupt keinen Ansatz für JPlay, wo es denn etwas Positives bewirkt. Es scheint mir eher den Ablauf zu stören, insofern es sich irgendwelche hohen Prioritäten verordnet und AC abwürgt.
Mir ist auch keine Schnittstelle bekannt, welche eine Verwendung a la
Player -> AcourateConvolver -> JPlay -> ASIO-Treiber
erlauben würde. Was bei Mehrwegesystemen auch die Kanalzahl bei JPlay aufblasen würde.
Bei rein Stereo mag natürlich die Aufteilung
offline-Convolution -> Player -> JPlay -> Treiber
ihren Sinn machen.
AC nützt alle verfügbaren Cores, die Faltungen der einzelnen Kanäle werden auf die Cores verteilt. Die virtuellen Cores sind nicht inbegriffen, da sie keine 64bit-Gleitkommaarithmetik haben.
Man braucht nicht unbedingt ProcessLasso, um die Cores für die jeweiligen Programme zuzuteilen. Ein einfacher Test kann z.B. mit dem Task Manager durchgeführt werden. Einfach unter Prozesse z.B. auf AcourateConvolver.exe rechtsklicken und 'Zugehörigkeit festlegen' wählen. Wenn man dann weiss, was man will, kann man das Programm auch per entsprechendes Batch-Kommando mit gewünchter Affinität starten.
Ich wundere mich immer ein bisschen über die ganze Hype um JPlay. Vor allem, dass es von Version zu Version immer besser wird. Was ja bedeutet, dass die Hausaufgaben davor nicht wirklich gemacht wurden. Letztendlich läuft alles darauf hinaus, die Anzahl an Prozessen zu reduzieren oder seitens der Priorität herunterzuschrauben. Es geht eben darum, die Wahrscheinlichkeit/Häufigkeit an "Störfällen" bei der Wiedergabe zu reduzieren. Und so findet sich ein Schräubchen hier und ein Quäntchen da, wo man dran drehen kann = nächste Version. Und weil alles nicht wirklich hilft (z.B. funkt der blöde Task-Scheduler immer noch dazwischen) trennt man nun Player und Soundkarte durch zwei PCs. Trotzdem muss der Soundkarten-PC die Daten auch noch einlesen (asynchroner Prozess zur Ausgabe) und zwischenpuffern und den Scheduler gibt es immer noch und die Kommunikation mit dem Grafikchip und den Netzwerktreiber ...
Grüsse
Uli
Grüße Fujak
_______________________________________________________________________________________________________
Mir fallen zu diesem Thema ein paar Gedanken ein, einfach mal ungeordnet aufgelistet:
Eine übliche Konfiguration mit JPlay wird wohl sein:
Player (z.B. Foobar) -> JPlay -> Soundkartentreiber (z.B. Asio)
Der Sinn von JPlay scheint mir hier zu sein, dass die Aufbereitung des Datenstroms für den Treiber (welcher immer an letzter Stelle kommt !) gleichmässiger wird. Dazu baut JPlay wohl einen entsprechenden Puffer auf und schraubt sich die Priorität entsprechend hoch.
Mit AcourateConvolver wäre die Kette dann so:
Player -> Jplay -> AcourateConvolver -> ASIO-Treiber
AcourateConvolver reagiert eventgesteuert auf den ASIO-Treiber und gibt zum einen Daten an den ASIO-Ausgangspuffer aus (festgelegt über die Soundkarte, üblicherweise 1024 bis 2048 Bytes/Kanal, keinesfalls 200 MB !). Zum anderen sammelt AC die Eingangsdaten (Puffergröße ebenfalls 1024 bis 2048 Bytes/Kanal) solange, bis ein für die Rechenlast günstiger Sammelpuffer (Größe = FFT-Partition) vorliegt.
Innerhalb des Prozesses sind die Prioritäten sauber gestuft, in absteigender Reihenfolge wären das: ASIO-Treiber -> Buffer Eventswitch -> Convolution -> GUI.
Ich sehe hier eigentich überhaupt keinen Ansatz für JPlay, wo es denn etwas Positives bewirkt. Es scheint mir eher den Ablauf zu stören, insofern es sich irgendwelche hohen Prioritäten verordnet und AC abwürgt.
Mir ist auch keine Schnittstelle bekannt, welche eine Verwendung a la
Player -> AcourateConvolver -> JPlay -> ASIO-Treiber
erlauben würde. Was bei Mehrwegesystemen auch die Kanalzahl bei JPlay aufblasen würde.
Bei rein Stereo mag natürlich die Aufteilung
offline-Convolution -> Player -> JPlay -> Treiber
ihren Sinn machen.
AC nützt alle verfügbaren Cores, die Faltungen der einzelnen Kanäle werden auf die Cores verteilt. Die virtuellen Cores sind nicht inbegriffen, da sie keine 64bit-Gleitkommaarithmetik haben.
Man braucht nicht unbedingt ProcessLasso, um die Cores für die jeweiligen Programme zuzuteilen. Ein einfacher Test kann z.B. mit dem Task Manager durchgeführt werden. Einfach unter Prozesse z.B. auf AcourateConvolver.exe rechtsklicken und 'Zugehörigkeit festlegen' wählen. Wenn man dann weiss, was man will, kann man das Programm auch per entsprechendes Batch-Kommando mit gewünchter Affinität starten.
Ich wundere mich immer ein bisschen über die ganze Hype um JPlay. Vor allem, dass es von Version zu Version immer besser wird. Was ja bedeutet, dass die Hausaufgaben davor nicht wirklich gemacht wurden. Letztendlich läuft alles darauf hinaus, die Anzahl an Prozessen zu reduzieren oder seitens der Priorität herunterzuschrauben. Es geht eben darum, die Wahrscheinlichkeit/Häufigkeit an "Störfällen" bei der Wiedergabe zu reduzieren. Und so findet sich ein Schräubchen hier und ein Quäntchen da, wo man dran drehen kann = nächste Version. Und weil alles nicht wirklich hilft (z.B. funkt der blöde Task-Scheduler immer noch dazwischen) trennt man nun Player und Soundkarte durch zwei PCs. Trotzdem muss der Soundkarten-PC die Daten auch noch einlesen (asynchroner Prozess zur Ausgabe) und zwischenpuffern und den Scheduler gibt es immer noch und die Kommunikation mit dem Grafikchip und den Netzwerktreiber ...
Grüsse
Uli
Hallo Ulli,
ich kann Deine Begeisterung teilen: Akustisch wieder ein Schritt vorwärts, es treten aber in meiner Kette noch viele Aussetzer auf (ohne hibernate mode), wenn ich hirez files abspiele. Diese Fehler nehmen zahlenmäßig und an "Intensität" zu, je mehr Titel einer CD bereits gespielt wurden. Mit 16/44.1 scheint es fehlerlos zu spielen.
Liebe Grüße,
Uwe
ich kann Deine Begeisterung teilen: Akustisch wieder ein Schritt vorwärts, es treten aber in meiner Kette noch viele Aussetzer auf (ohne hibernate mode), wenn ich hirez files abspiele. Diese Fehler nehmen zahlenmäßig und an "Intensität" zu, je mehr Titel einer CD bereits gespielt wurden. Mit 16/44.1 scheint es fehlerlos zu spielen.
Liebe Grüße,
Uwe
Hallo Ulli und Uwe,
auch ich finde, dass RC2 klanglich das beste aus den bisherigen Versionen in sich vereinigt, insbesondere die Verbindung aus Wärme und feiner Auflösung (in Verbindung mit Foobar 0.8.3).
Was auch mir nicht behagt, sind die Schwierigkeiten im Abspielen. Auf meinem Audio-PC klappt alles problemlos (=jede Samplerate, jeder Modus), der Einsatz auf meinem Office-PC aber führt zu Stottern bei der Wiedergabe, was bei RC1 nicht der Fall war. Zudem braucht der Start der Wiedergabe mehr Zeit als mit RC1. Beide Phänomene übrigens unabhängig von der Samplerate oder Länge des Stückes (egal ob NonThrottle, Throttle oder Hibernate). Daran sehe ich, wieviele Faktoren offenbar noch berücksichtig werden müssen, bis JPlay in der Endfassung von Vers. 5 auf jedem PC lauffähig ist.
Grüße
Fujak
auch ich finde, dass RC2 klanglich das beste aus den bisherigen Versionen in sich vereinigt, insbesondere die Verbindung aus Wärme und feiner Auflösung (in Verbindung mit Foobar 0.8.3).
Was auch mir nicht behagt, sind die Schwierigkeiten im Abspielen. Auf meinem Audio-PC klappt alles problemlos (=jede Samplerate, jeder Modus), der Einsatz auf meinem Office-PC aber führt zu Stottern bei der Wiedergabe, was bei RC1 nicht der Fall war. Zudem braucht der Start der Wiedergabe mehr Zeit als mit RC1. Beide Phänomene übrigens unabhängig von der Samplerate oder Länge des Stückes (egal ob NonThrottle, Throttle oder Hibernate). Daran sehe ich, wieviele Faktoren offenbar noch berücksichtig werden müssen, bis JPlay in der Endfassung von Vers. 5 auf jedem PC lauffähig ist.
Grüße
Fujak
Liebe JPlay-Freunde!
Ich bin ja froh dass ich nicht der Einzige bin, der Probleme mit dem Abspielen von hirez Aufnahmen hat. Genauer gesagt: JPlay mit SAP verarbeitet alles, ist aber bei hirez nicht so wohlklingend wie Foobar mit JPlay. SAP hat da einen Hang schrill zu werden. Auch meine ich leichtes Knacksen zu hören. Jplay mini kann keine hirez. Weder als FLAC noch als WAV. Mit 16/44 und 24/44 geht es saugut. Das ist das beste was ich bei mir gehört habe. 24/96 habe ich noch nicht probiert. Foobar mit JPlay kann auch alles klingt aber nicht so homogen wie JPlay mini. Aber: Gestern Abend traten auch Aussetzer (bei 16/44) auf und ASIO stürzte laut Fehlermeldung ab. Nach Neustart lief alles wie gewohnt gut.
Ich habe zwei CDs bei highresaudio.de mit 24/44 herunter geladen. Foobar mit JPlay beendet diese nach ca 2 Minuten. Danach lässt sich die CD nicht mehr in Foobar starten. Mit anderen CDs im gleichen Format bei Linn herunter geladen tacht das nicht auf. Die genannten CDs lassen sich im JPlay mini und SAP wunderbar abspielen. Weiss einer warum Foobar streikt?
Ich habe von Bachs Weihnachtsoratorium eine Aufnahme mit 69 Tracks. Jplay mini nimmt aber nur 45 an. Ist das normal?
Ich freu mich über Eure Antworten
Herzliche Grüße
Snilax
Ich bin ja froh dass ich nicht der Einzige bin, der Probleme mit dem Abspielen von hirez Aufnahmen hat. Genauer gesagt: JPlay mit SAP verarbeitet alles, ist aber bei hirez nicht so wohlklingend wie Foobar mit JPlay. SAP hat da einen Hang schrill zu werden. Auch meine ich leichtes Knacksen zu hören. Jplay mini kann keine hirez. Weder als FLAC noch als WAV. Mit 16/44 und 24/44 geht es saugut. Das ist das beste was ich bei mir gehört habe. 24/96 habe ich noch nicht probiert. Foobar mit JPlay kann auch alles klingt aber nicht so homogen wie JPlay mini. Aber: Gestern Abend traten auch Aussetzer (bei 16/44) auf und ASIO stürzte laut Fehlermeldung ab. Nach Neustart lief alles wie gewohnt gut.
Ich habe zwei CDs bei highresaudio.de mit 24/44 herunter geladen. Foobar mit JPlay beendet diese nach ca 2 Minuten. Danach lässt sich die CD nicht mehr in Foobar starten. Mit anderen CDs im gleichen Format bei Linn herunter geladen tacht das nicht auf. Die genannten CDs lassen sich im JPlay mini und SAP wunderbar abspielen. Weiss einer warum Foobar streikt?
Ich habe von Bachs Weihnachtsoratorium eine Aufnahme mit 69 Tracks. Jplay mini nimmt aber nur 45 an. Ist das normal?
Ich freu mich über Eure Antworten
Herzliche Grüße
Snilax
Hallo JPlay-Freunde,
Aber welche Rolle spielt die Bedienoberfläche in der Audiowiedergabe bei jplay überhaupt noch ?
Ich dachte das ist nur noch die Bedienoberfläche, die mit der Audiowiedergabe selbst nichts mehr zu tun hat ( z.B. bei foobar ist Fortschrittsbalken ohne Funktion ) ?
Also im Prinzip einer von vielen weiteren Prozessen die von jplay mit speziellen Mechanismen, während der Wiedergabe, sogar herunter priorisiert werden.
Viele Grüße
Maximilian
der Grad zwischen optimalen Klang und reibungslosen Abspielen ist auf den Niveau vermutlich sehr schmal geworden, dennoch sollte man jplay über die Optionen auf vielen unterschiedlichen Rechner zum reibungslosen Abspielen bekommen, was in der V5 momentan noch nicht der Fall ist.Was auch mir nicht behagt, sind die Schwierigkeiten im Abspielen. Auf meinem Audio-PC klappt alles problemlos (=jede Samplerate, jeder Modus), der Einsatz auf meinem Office-PC aber führt zu Stottern bei der Wiedergabe …
Die Bedienoberflächen (foobar, und davon sogar unterschiedliche Versionen) scheinen trotz Jplay einen Einfluß auf den Klang zu haben.... RC2 klanglich das beste aus den bisherigen Versionen in sich vereinigt, insbesondere die Verbindung aus Wärme und feiner Auflösung (in Verbindung mit Foobar 0.8.3).
Aber welche Rolle spielt die Bedienoberfläche in der Audiowiedergabe bei jplay überhaupt noch ?
Ich dachte das ist nur noch die Bedienoberfläche, die mit der Audiowiedergabe selbst nichts mehr zu tun hat ( z.B. bei foobar ist Fortschrittsbalken ohne Funktion ) ?
Also im Prinzip einer von vielen weiteren Prozessen die von jplay mit speziellen Mechanismen, während der Wiedergabe, sogar herunter priorisiert werden.
Viele Grüße
Maximilian
Hallo Maximilian,
mit JPLAY gibt es einiges zu entdecken, was sich meinem Verständnis entzieht und mir nur "aural" erfassbar erscheint. Davon ist die Bedienoberfläche 1 Punkt (die Audiophilität von foobar 0.8.3 hat ja Marcin ins Gespräch gebracht). Vom Entwickler stammt auch der Hinweis, einen Klanggewinn mit Total Commander als shell zu bekommen. Gleiches hat er auch bemerkt, wenn ein Musik-file nach c: kopiert wird und - sofern man in die TC shell gebootet ist - mit dem Total Commander den file seines Titels "beraubt" und dann abspielt. Dieses habe ich noch nicht ausprobiert und kann in diesem thread nachgelesen werden:
http://jplay.eu/forum/jplay/system-optimization-jplay/
Liebe Grüße,
Uwe
mit JPLAY gibt es einiges zu entdecken, was sich meinem Verständnis entzieht und mir nur "aural" erfassbar erscheint. Davon ist die Bedienoberfläche 1 Punkt (die Audiophilität von foobar 0.8.3 hat ja Marcin ins Gespräch gebracht). Vom Entwickler stammt auch der Hinweis, einen Klanggewinn mit Total Commander als shell zu bekommen. Gleiches hat er auch bemerkt, wenn ein Musik-file nach c: kopiert wird und - sofern man in die TC shell gebootet ist - mit dem Total Commander den file seines Titels "beraubt" und dann abspielt. Dieses habe ich noch nicht ausprobiert und kann in diesem thread nachgelesen werden:
http://jplay.eu/forum/jplay/system-optimization-jplay/
Liebe Grüße,
Uwe
Hallo Uwe,
und aller anderen Prozesse auf dem Rechner deutlich verringern.
Dem ist scheinbar momentan (noch) nicht oder nur teilweise so.
Hoffentlich kommen in der Richtung noch weitere Schritte mit der V5.
Da bleibt nur ausprobieren oder abwarten
Viele Grüße
Maximilian
Ich hatte erhofft, dass die “speziellen Mechanismen“ von jplay, den Einfluss der Oberflächemit JPLAY gibt es einiges zu entdecken, was sich meinem Verständnis entzieht und mir nur "aural" erfassbar erscheint.
und aller anderen Prozesse auf dem Rechner deutlich verringern.
Dem ist scheinbar momentan (noch) nicht oder nur teilweise so.
Hoffentlich kommen in der Richtung noch weitere Schritte mit der V5.
Da bleibt nur ausprobieren oder abwarten
Viele Grüße
Maximilian
Hallo Maximilian,
JPlay basiert ja gerade auf der Erkennntnis, dass alles, was im Audio-PC passiert, Einfluss auf den Klang haben kann. JPlay ist eine Audio-Engine plus einer internen Einheit, die diverse Prozesse, Dienste, Threads abschaltet, weil sie Einfluss haben auf den Klang, für die Musikwiedergabe aber nicht vonnöten sind.
Dass damit alles deaktiviert worden wäre, was Einfluss auf den Klang hat, wäre ein unzulässiger Umkehrschluss. So bleiben z.B. die Einflussfaktoren der GUI bestehen, sofern es sich um eine Single-PC-Konfiguration handelt (auf einer Dual-PC-Konfiguration schwindet dieser Einfluss erheblich). Nicht umsonst hat das GUI-freie JPlaymini den besten Klang.
Grüße
Fujak
JPlay basiert ja gerade auf der Erkennntnis, dass alles, was im Audio-PC passiert, Einfluss auf den Klang haben kann. JPlay ist eine Audio-Engine plus einer internen Einheit, die diverse Prozesse, Dienste, Threads abschaltet, weil sie Einfluss haben auf den Klang, für die Musikwiedergabe aber nicht vonnöten sind.
Dass damit alles deaktiviert worden wäre, was Einfluss auf den Klang hat, wäre ein unzulässiger Umkehrschluss. So bleiben z.B. die Einflussfaktoren der GUI bestehen, sofern es sich um eine Single-PC-Konfiguration handelt (auf einer Dual-PC-Konfiguration schwindet dieser Einfluss erheblich). Nicht umsonst hat das GUI-freie JPlaymini den besten Klang.
Grüße
Fujak
Hallo Fujak,
Die Frage ist was macht die GUI eigentlich während des Wiedergabe um den Klang zu beeinträchtigen ?
Eigentlich sollte sich das auf das Warten einer Nutzereingabe beschränken ( z.B. Klicken auf Pause ) ?
Dass dies trotz der jplay Mechanismen ( wie eigenen Kern für Audio-Engine verwenden, etc. )
auch auf Mehrkernrechner zu klangrelevanten Veränderungen führt, ist doch sehr erstaunlich.
Aber da auf einem Rechner alles logisch abläuft, müsste es doch für die Hörerfahrung einen
technisch nachvollziehbaren Grund geben ?
Grüße
Maximilian
So neu ist die Erkenntnis nicht, schon andere Player ( z.B. cmp²/cplay ) basierten auf der Erkenntnis.JPlay basiert ja gerade auf der Erkennntnis, dass alles, was im Audio-PC passiert, Einfluss auf den Klang haben kann.
richtig, ein sehr guter Ansatz.JPlay ist eine Audio-Engine plus einer internen Einheit, die diverse Prozesse, Dienste, Threads abschaltet, weil sie Einfluss haben auf den Klang, für die Musikwiedergabe aber nicht vonnöten sind.
Auch diese Erfahrungen gibt es bereits seit cmp²/cplay, SAP, etc.So bleiben z.B. die Einflussfaktoren der GUI bestehen. …. Nicht umsonst hat das GUI-freie JPlaymini den besten Klang.
Die Frage ist was macht die GUI eigentlich während des Wiedergabe um den Klang zu beeinträchtigen ?
Eigentlich sollte sich das auf das Warten einer Nutzereingabe beschränken ( z.B. Klicken auf Pause ) ?
Dass dies trotz der jplay Mechanismen ( wie eigenen Kern für Audio-Engine verwenden, etc. )
auch auf Mehrkernrechner zu klangrelevanten Veränderungen führt, ist doch sehr erstaunlich.
Aber da auf einem Rechner alles logisch abläuft, müsste es doch für die Hörerfahrung einen
technisch nachvollziehbaren Grund geben ?
Grüße
Maximilian
-
uli.brueggemann
- Aktiver Hersteller
- Beiträge: 4672
- Registriert: 23.03.2009, 15:58
- Wohnort: 33649
- Kontaktdaten:
ich hab's befürchtet, oberflächlich gesehen hast Du schon rechtZum Beispiel die Anzeige der Uhrzeit rechts unten im Tray updaten ?
Was schlägst Du vor, die Zeit an zu halten, auf den Freitag im Maja Kalender zu hoffen ?
Zurück zum Thema, wenn in der Kombi jplay+foobar nicht mal mehr der Fortschrittbalken der Wiedergabe
aktualisiert wird, ist die Player GUI eine sehr statische Angelegenheit geworden, die für die Anzeige entsprechen ( wenig ) Ressorcen brauchen sollte. Aber selbst veschiedene foobar Versionen die nur als GUI genutzt werden,
scheinen sich zu unterscheiden. Also müssen da doch noch andere Dinge passieren ?
Ein Vergleich fällt schwer, ein online Convolver dürfte doch mehr Ressorcen brauchen als eine statische Player-GUI ?
Grüße
Maximilian