[RPI Ausgabeplugin] Knacken

  • Hi Thomas

    aber welches Problem genau meinst du? Knackser bei Live-TV oder bei der Wiedergabe von Aufnahmen?


    bei mir hat es beide Probleme behoben. Wobei ich nicht weis, ob das beim Live-TV auch schon früher mit der neuesten GIT-Version behoben war. (Ich habe mehr auf das Audio-Video-Problem bei Aufzeichnungen geachtet)


    Patrick

  • Also das Tonknacksen kenne ich mit der aktuelle MLD auch. Mir ist es ebenfalls ausschließlich bei SD Sendern aufgefallen. Meiner ist auch per HDMI direkt am LCD angeschlossen.
    Ich habe den aber erst seit einer Woche und es stört nur geringfügig, zumindest kaum im Vergleich zum Bildruckeln bei 1080p Signalen.


    @Patrick
    bei mir sieht das, egal welcher HDMI Modus ich bei FullHD (also egal ob 60 oder 50Hz und I oder p) wähle , so aus wie als wenn die Frames springen würden und bei Bewegungen könnte man es als eine Art Strobo Effekt beschreiben. Ab und zu bekommt sich das Signal wieder ein, um dann ein paar Sekunden später wieder damit anzufangen.


    Möglich dass es auch mit dem DD Ton zu tun hat, denn ich habe die hdmi_forece_edid noch nicht angetastet, also auf 0.

    Proxmox VE, Tyan Xeon Server, OMV, MLD-Server 5.1
    MLD 5.1 64bit: Asus AT5iont-t, ION2, 4GB Ram, SSHD 2,5" 1Tb, HEX TFX 300W 82+, Cine S2 V6.2 , 38W max.
    Yavdr 0.5:
    Zotac D2550ITXS-A-E mit GT610 OB, TT S2-4100 PCI-e ,Joujye NU-0568I-B
    Yavdr 0.5:
    Sandy Bridge G840, Tests und Energieverbrauch , CoHaus CIR, Cine S2 V6.2
    MLD 5.1 Beebox N3150
    , DVBSky S960 und 1Tb WD Blue

  • Tach zusammen

    Falls es jemand mal testen will? Ich habe das gerade erst gesehen...

    ich werde es direkt mal testen. Das hört sich genau nach unserem Problem an. Ich werde ein Feedback geben.


    VG
    mcfly

    Raspberry Pi B+
    overclocked 950 MHZ
    mem/gpu split 256/256
    VDR 2.1.6 mit rpihddevice und streamdev aus dem git
    HDMI Splitter

  • Mag mal jemand zusammenfassen was zu tun ist, um den Fix zu testen? Ist lediglich nen Update auf die neuste Firmware erforderlich oder noch weitere bzw. andere Schritte?


    Claus

    MLD 5.5 mit vdr 2.6 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM - WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.5 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.5 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT

  • Dann bin ich ja mal gespannt ob es hilft... Ich werde testen und berichten

    Proxmox VE, Tyan Xeon Server, OMV, MLD-Server 5.1
    MLD 5.1 64bit: Asus AT5iont-t, ION2, 4GB Ram, SSHD 2,5" 1Tb, HEX TFX 300W 82+, Cine S2 V6.2 , 38W max.
    Yavdr 0.5:
    Zotac D2550ITXS-A-E mit GT610 OB, TT S2-4100 PCI-e ,Joujye NU-0568I-B
    Yavdr 0.5:
    Sandy Bridge G840, Tests und Energieverbrauch , CoHaus CIR, Cine S2 V6.2
    MLD 5.1 Beebox N3150
    , DVBSky S960 und 1Tb WD Blue

  • So, bin jetzt zum Testen gekommen. Ich benutze den Analogaussgang und speise damit einen Monitor mit Lautsprechern. Damit knackt es immernoch, hin und wieder klingt es wie ein Zirpen - aktuell auf WDR HD im LiveTV. Ich habe den Buffer auf 8 erhöht, aber das bringt leider nix.


    Wie schaut es bei euch aus?


    Gruss, ollo

  • Hast du ein seperates Netzteil für den RPI oder hängt der evtl. auch am Monitor, so dass du dir eine Brummschleife baust?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hallo Gemeinde,


    ich habe nun auch das rpi-update durchgeführt, in der Hoffnung dass das Knacken besser wird.
    Jedoch ohne Erfolg. Ich benutze ein separates Netzteil für den Pi. Um das Kancken nun wieder ein wenig weg zu bekommen, baue ich nun wieder die 2 Vorschläge in das omxdevice.c (define auf 1 sek.) und omx.c (audiobuffer auf 16) ein.
    Ich hoffe wir können dieses Problem in der Zukunft beheben, denn ansonsten läuft der Pi super...


    P.S. Ich hatte in einem anderen Themengebiet (hier im Forum) eine Frage gestellt bzgl. mp3 und jpg. Bislang keine Antworten. Ist das eine doofe Frage oder wieso ? Vlcht. kann der ein oder andere ja mal dort was zu schreiben ?!


    VG
    mcfly

    Raspberry Pi B+
    overclocked 950 MHZ
    mem/gpu split 256/256
    VDR 2.1.6 mit rpihddevice und streamdev aus dem git
    HDMI Splitter

  • Hallo allerseits


    Ich würde gerne ein wenig Übersicht in die Audio-Probleme bringen, denn ich vermute, da wird einiges durcheinander gebracht. Mir sind aktuell folgende Probleme bekannt:


    Audio-Aussetzer, evtl. in Kombination mit Bildrucklern, Buffer-Stall-Meldungen im Log
    Dies hat mit der Bufferverteilung zu tun, das Erhöhen der Audio-Buffer sollte im Live-Mode das Problem beheben. Ich habe die Audio-Buffer bisher knapp gehalten um die Trick-Speeds besser handeln zu können. Aber da muss ich sowieso noch einmal ran - steht aktuell zu oberst auf meiner To-Do-Liste.

    Störgeräusche nur am Analogport, hörbar vor allem während leisen Passagen

    Die Stromversorgung des Analogports auf dem Raspberry Pi ist nicht entkoppelt, wodurch je nach Last eine Art Zirpen hörbar ist. Das Geräusch ändert sicht ja nach Last und kann zwischen HD/SD oder Live-TV/Replay durchaus unterschiedlich sein. Dies ist ein Hardwareproblem und lässt sich per Software nicht beheben. Die B+-Variante ist hiervon weniger betroffen, ganz behoben ist das Problem aber auch hier nicht.


    Störgeräusche auch über HDMI, hörbar vor allem während leisen Passagen
    Wurde mir bisher nur von GTRDRIVER berichtet, habe ich aber selber noch nie beobachtet. Hat vielleicht etwas mit dem Firmware Issue #324 zu tun... mehr kann ich dazu nicht sagen.


    Es wäre gut, je nach Problem die Diskussion in einem separaten Thread zu führen, ansonsten gestaltet sich eine strukturierte Analyse schwierig...


    Gruss
    Thomas

  • Weiterer Punkt:


    Zu hohe Erwartungen bzw. Unverstand der User was Passthru und Downmix betrifft:
    Der Raspberry hat scheinbar zu wenig Schmalz um 5.1 auf 2.0 herunterzurechnen - korrekt?


    Vielleicht wäre es möglich eine Art "Diagnose" Ausgabe dem User anzuzeigen. Wenn der HDMI des Fernsehers halt nur 2.0 hat dann macht es keinen Sinn im VDR 5.1 Sound zu wählen.


    lg,
    Joe

  • Zu hohe Erwartungen bzw. Unverstand der User was Passthru und Downmix betrifft:
    Der Raspberry hat scheinbar zu wenig Schmalz um 5.1 auf 2.0 herunterzurechnen - korrekt?

    Stimmt, den Punkt habe ich vergessen. Stereo-Downmix von 5.1 mit Resampling ist tatsächlich suboptimal und führt zwischenzeitlich zu Rucklern. Hier muss ich schauen, ob sich das Problem mit mehr Buffern beheben lässt.


    Vielleicht wäre es möglich eine Art "Diagnose" Ausgabe dem User anzuzeigen. Wenn der HDMI des Fernsehers halt nur 2.0 hat dann macht es keinen Sinn im VDR 5.1 Sound zu wählen.

    Eleganter wäre, in cDevice eine Funktion einzuführen, ob das Device Mehrkanalton (bzw. gleich ein konkretes Format) unterstützt. Aber dazu müsste der VDR in die Daten reingucken, und das will Klaus nicht - schade aber verständlich. Eine Warnung ins Log wäre aber wohl angebracht.


    Gruss
    Thomas

  • Hi,
    so nach längerer Testzeit nun der aktuelle Stand hier bei mir:


    Setup:

    • RPI mitraspbian und 2A Netzteil
    • Buffererhöhung auf 16
    • Samsung TV direkt mit HDMI angeschlossen
    • Aufnahmen über NFS vom VDR-Server gemoutet
    • Stremdev-(Client|Server)


    Live TV geht fast problemlos mit nur sehr kleinen für mich nicht störenden Audio-Plops. Das hört sich fast so an als ob ab und an Audio-Samples an der falschen Stelle früher oder später abgespielt werden.


    Aufzeichnungen anschauen:
    Wenn auf dem Server keine gleichzeitige Aufnahme läuft, dann wird das problemlos abgespielt, wie bei Live-TV.
    Wenn man eine Aufnahme anschaut, die gerade aufgezeichnet wird, dann kommt es ca. jede Sekunde zu Audio- und Bild-Stockungen. Das könnte ein Performance-Problems ein. Doch was löst bei einer Aufnahme auf dem Server periodisch eine höhere Last auf dem Client aus? Kann es sein dass der Client-VDR da mitbekommt, dass sich was am Aufnahme-Verzeichnis geändert hat und dadurch immer wieder irgendetwas neu einliest, was dann zur erhöhten Last und dann zu den Stockungen führt? Wenn die Aufnahme dann am Server fertig ist, dann verschwinden die Ruckler sofort. Da der Client mit LAN-Kabel mit dem Server verbunden ist (kein WLAN dazwischen) denke ich, dass es kein Übertragungsproblem ist.


    Hat noch jemand das gleiche Verhalten bei gleichzeitigen Aufnahmen?


    Greets
    Patrick

  • ich habe meinen Produktiv RasPI mit MLD vor ein paar Tagen leider upgedated. Dabei ist auch eine neue Version von diesem Plugin rein gekommen. Seite dem habe ich auch deutlich mehr Knacken und Ruckler. Besonders bei HD TV. Aufnahmen laufen dagegen ruckelfrei.


    Ich bin auf ein Problem mit der aktuellen Version des Plugins gestossen, wobei der VDR beim Replay wegen eines falsch gesetzten Mutex scheinbar den Audio-Decoder des Plugins ausbremst. Das ist nun gefixt und "Life Of Pi" läuft mit DTS-Pass-Through wieder ohne zu Ruckeln...


    Gruss
    Thomas

  • Stimmt, den Punkt habe ich vergessen. Stereo-Downmix von 5.1 mit Resampling ist tatsächlich suboptimal und führt zwischenzeitlich zu Rucklern. Hier muss ich schauen, ob sich das Problem mit mehr Buffern beheben lässt.


    Kurzer Nachtrag: Stereo-Downmix von 5.1-AC3 funktioniert definitiv auch mit Resampling wunderbar. Als Beispiel läuft bei mir gerade der TS-Stream von Coldplay - Live 2012 mit ca. 50% CPU-Last über NFS - auch die kritische Stelle bei 7:30 (Papierschnitzel fliegen durch die Luft) ruckelt nicht.


    Anders bei DTS, hier läuft nur Pass-Though flüssig...


    Gruss
    Thomas

  • Danke fürs dran bleiben!


    Wäre es sinnvoll einen neuen Release zu machen wenn so etwas wichtiges gefixed wurde?


    Die Version 0.1.0 wär doch passend? :tup


    lg,
    Joe

  • Wäre es sinnvoll einen neuen Release zu machen wenn so etwas wichtiges gefixed wurde?


    Die Version 0.1.0 wär doch passend? :tup

    Vor der 0.1.0 - das wäre dann die Beta - will ich noch ein Problem bei den Trick Speeds lösen. Aktuell bleibt die Wiedergabe stecken, wenn man direkt vom schnellen Vor- in den -Rücklauf wechselt. Aber dieser Bug ist ein wenig haarig, weshalb ich ihn schon länger vor mir her schiebe... :|


    Gruss
    Thomas

  • Verstehe,
    naja wie die Version heißt ich ja nicht so relevant aber ich denke die Distributionersteller sehen das es was wichtiges neues gibt.
    Oder ist das dank Git eh kein Thema mehr?
    Sorry für das OT.


    lg,
    Joe

  • naja wie die Version heißt ich ja nicht so relevant aber ich denke die Distributionersteller sehen das es was wichtiges neues gibt.
    Oder ist das dank Git eh kein Thema mehr?


    Ok, spricht eigentlich nichts dagegen, eine 0.0.10 zu machen - sind ja auch ein paar neue Features dazugekommen. Werde am Wochenende das entsprechende Tag comitten, wenn bis dahin keine neuen Fehler auftauchen.


    Gruss
    Thomas

Jetzt mitmachen!

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