NUC6CAYH mit Libreelec kein DTS-HD über Passthrough

  • Dann wurde ich ja offensichtlich doch verstanden, denn hier war bisher weder von falschen Kanalzuordnungen, nicht von Netflix Streams die Rede, welche eh nicht betroffen wären, da es hier ja eigentlich um HD Streams ging. ;)

    Gesendet von meinem Redmi Note 3 mit Tapatalk

    95% aller Computerfehler sitzen vor dem Bildschirm!

  • Ich kann nach meinen Tests am Sony-Verstärker sagen:
    es macht einen deutlichen Unterschied. Das liegt am Sony :D
    Bei mir ist PCM so nicht zu gebrauchen. Viele Einstellungen bekomme ich dann erst gar nicht. Egal wie ich es drehe.
    (Wobei ich auf jeden Fall auch diverse Pusher verwende. Dafür habe ich es ja. Ich verwende bei Film sogar automatische Lautstärkereglung - einfach weil es dabei für mich besser klingt.)
    Und auch Pure-Direct klingt flacher. Also noch flacher als DTS in pure direct.
    Ist mir aber auch egal. Bei meinem Filmgehör reicht AC3. Musik die dicken 320er mp3s.
    Ob das jetzt mit anderer Hardware anders ist, kann ich auch nicht sagen. Aber es kann hardwarebedingt durchaus problematisch werden.

  • Das hängt tatsächlich von Receiver ab. Bei meinem Denon funktionieren die Eqs und DRC auch mit PCM Daten. ;)

    Deshalb macht es für mich z. B. keinen Unterschied ob PCM oder nicht...

    Gesendet von meinem Redmi Note 3 mit Tapatalk

    95% aller Computerfehler sitzen vor dem Bildschirm!

  • Das hängt tatsächlich von Receiver ab. Bei meinem Denon funktionieren die Eqs und DRC auch mit PCM Daten. ;)

    Deshalb macht es für mich z. B. keinen Unterschied ob PCM oder nicht...

    Gesendet von meinem Redmi Note 3 mit Tapatalk

    Wäre mir neu, wenn ein Receiver bei einem eingehenden PCM Signal irgendwie DRC anwenden könnte. Über was für einen Weg sollen dann die DRC metadaten übertragen werden? Höchstens manuell sowas wie "night mode" oder so, aber das normale drc würde ja dem PCM Prinzip widersprechen, welches einfach stumpf einen lossless Datenstrom überträgt. Du könntest höchstens DRC beim dekodieren durch kodi berücksichtigt bekommen und in den PCM stream reinenkodiert bekommen, bevor der an den Receiver geschickt wird. Und da landen wir wieder bei der Problematik, dass es nicht immer so klar ist, ob kodi/treiber/software-bugs da das drc falsch reinrechnen. Der Receiver bekommt den fertigen PCM stream geschickt und spielt den einfach so ab, wie er kommt. EQ am Receiver kann man bei den meisten AVRs dann wohl noch auf PCM anwenden (wüsste keinen Grund warum das technisch nicht ginge), aber das habe ich nie probiert, da ich immer passthrough nutze.

  • Ich glaube ja ehrlich gesagt, dass die Problematik eher daher rührt, dass gewisse User einfach bei PCM-Spuren keine EQ´s mehr in Ihrem AVR nutzen können und sich daher natürlich der Ton wesentlich dünner und einfach schlechter anhört.

    Ich habe gerade noch mal spasseshalber bei mir getestet und höre da: Kein Unterschied und alle EQ´s laufen. ;)

    Die Endgeräte spielen also mit Sicherheit auch eine große Rolle. Kodi hat DRC Support, in wie fern der bei PCM zum Tragen kommt, kann ich nicht sagen...

    95% aller Computerfehler sitzen vor dem Bildschirm!

  • Ich glaube ja ehrlich gesagt, dass die Problematik eher daher rührt, dass gewisse User einfach bei PCM-Spuren keine EQ´s mehr in Ihrem AVR nutzen können und sich daher natürlich der Ton wesentlich dünner und einfach schlechter anhört.

    Ich habe gerade noch mal spasseshalber bei mir getestet und höre da: Kein Unterschied und alle EQ´s laufen. ;)

    Die Endgeräte spielen also mit Sicherheit auch eine große Rolle. Kodi hat DRC Support, in wie fern der bei PCM zum Tragen kommt, kann ich nicht sagen...

    Ja da sagst du es ja selbst... Man kann es halt nicht verifizieren, wie gut und wie korrekt die kodi Implementierung ist. Zudem kann das auf jeder Hardware zu einem anderen Ergebnis führen, ohne passthrough, weils halt auch treiberabhängig sein kann.
    Bei passthrough kannst du mit viel größerer Sicherheit sagen, dass es korrekt implementiert ist, weil AVRs massenweise vertrieben werden und esvin der Hardware steckt. Wäre da ein bug, ginge es für die gesamte AVR-Serie an die Öffentlichkeit und ziehe eine Rückrufaktion oder ein Firmwareupdate nach sich.

  • Update: (Stand 28.06.2017)
    Problem besteht weiterhin mit MH#626 & 4.11.7 Kernel

    Ich warte schon seit Februar auf ein Update :confused:

    Man kann nur hoffen, dass die nächsten Monate da noch etwas passiert.

    Meine Hardware


    Clients: 3x Nvidia Shield TV
    NAS: Synology DS1815+ (32TB) + DS 214 Play <-> Safe: APC Back UPS PRO USV
    Netzwerk: Modem-->Fritzbox 6490 (KD), Switch-->Netgear GS116E, Netgear GS108
    Smarthome: diverse Homematic + HUE-Lampen gesteuert/automatisiert über IPSymcon + Node-Red
    AccessPoint: Netgear R6200, Netgear Nighthawk X4R7500
    Sound & TV: Marantz SR7009 mit Magnat 7.1.4 --> Philips 65PFK6520

  • Der NUC enthält einen J3455 Prozessor. Ein Apollo Lake Prozessor mit einem "defekten" LSPCon DP zu HDMI Konverter. Unter Windows ist die gewünschte Audio-Ausgabe möglich miitels Firmwareupdate auf Version 1.66. Leider gibt es noch kein Update für Linux.

    Den aktuellen Status kannst du im Thread Apollo Lake im Kodi Forum verfolgen. Folgend der Link dahin:
    https://forum.kodi.tv/showthread.php…dp+to+hdmi+chip
    Da kann auch ein Milhouse nichts daran ändern.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!