Artefakte in HD-Aufnahmen mit TT-S6400

ja OK,
dann wird wohl der Tuner ausscheiden. Es wäre noch die Möglichkeit die Interrupt-Behandlung zu ändern (siehe sg75s Beitrag)

Powarman hatte damals das Handling eingebaut --> TechnoTrend Premium S2-6400 Artefakte

Aber es gab wohl trotzdem einige hartnäckige Boarde, die sich quer stellten.

Ich habe die besten Erfahrungen mit int-type=0. Auch nehme ich mindestens phi_mode=1. phi_mode=2, wenn das noch funktioniert (geht nicht mit allen CPUs - hier hast Du ja leider auch etwas Exotisches ausgesucht).

Kannst Du mal die Ausgabe von 'top -H' posten, wenn ein HD-Sender mit moeglichst hoher Bitrate wiedergegeben wird!?

Gruss,
S:oren

Hi,

treten die Probleme auch bei SD Aufnahmen auf? Und wie ich das sehe wissen wir noch nicht ob es auf der Aufnahme oder der Wiedergabeseite liegt. Kopier doch mal eine Aufnahme auf einen anderen Rechner und guck dir an ob wenn z.B. mit VLC abgespielt wird auch Probleme auftreten.

bye
Sven

Zitat von Phantom-ZXR

Hatte wirklich nicht gedacht, wie speziell die Auswirkungen auf das System vom richtigen Prozessor und Board sind. [...] Muss ich eben nochmal investieren.

Neue Hardware muss nicht sein, denke ich. Da kann man (hoffentlich) auch im Treiber noch etwas machen. Ich habe hier einen Patch in Arbeit, den ich ueber die Feiertage noch besser testen will.
Gelegentlich habe ich auch Probleme mit fehlenden Daten in Aufnahmen und entsprechende Artefakte, allerdings auch nur in einem exotischen Setup mit ARM-Cortex-A9-Quadcore und 4 USB-Tunern. Mit nur einem aktiven CPU-Kern funktioniert es z.B. problemlos, da koennte also auch ein Locking-Problem im media-Treiber-Framework selbst schuld sein. Das ist jetzt ein ganz neuer Aspekt: Was haben USB-Tuner (bei mir) und S2-6400-Tuner (bei Dir) gemeinsam, die demux-Treiber, DMA-Completion-Worker? Hoffentlich finde ich hier erstens Zeit zum Debuggen, und zweites dann auch den Bug...

Speziell phi_mode ist sehr CPU-abhaengig. Bei manchen CPUs ist alles unter phi_mode=2 unendlich langsam (z.B. VIA, aeltere ARM-Architekturen), auf anderen CPUs geht phi_mode=2 nicht, da ist aber normalerweise phi_mode=1 auch schnell genug. Deine CPU ist also vermutlich nicht wirklich ein Problem, nur hat dafuer - so weit ich weiss - noch niemand ausprobiert, welcher phi_mode der richtige ist. Wenn Du die Ausgabe von 'top -H' postest (und inbesondere die CPU-Last der kworker-Threads), dann koennte ich hier vielleicht einen Tipp geben.

Der richtige int_type ist wohl eher vom Board abhaengig, und insbesondere davon, ob man mehrere PCIe-Karten oder on-board-Komponenten hat, die sich Interrupts teilen. Da ich in meinen VDRs neben der Decoderkarte keine weiteren PCIe-Karten verwende, hat int_type=0 bei mir immer bestens funktioniert. Ich kann mir nicht vorstellen, dass mit halbwegs aktuellen Linux-Kerneln und einer typischen Hard-IRQ-Last unter 2% MSI noch irgendeinen Vorteil bietet. Andere Leute haben da aber anscheinend andere Erfahrungen gemacht.

Gruss,
S:oren

Zitat von S:oren

Gelegentlich habe ich auch Probleme mit fehlenden Daten in Aufnahmen und entsprechende Artefakte, allerdings auch nur in einem exotischen Setup mit ARM-Cortex-A9-Quadcore und 4 USB-Tunern. Mit nur einem aktiven CPU-Kern funktioniert es z.B. problemlos, da koennte also auch ein Locking-Problem im media-Treiber-Framework selbst schuld sein. Das ist jetzt ein ganz neuer Aspekt: Was haben USB-Tuner (bei mir) und S2-6400-Tuner (bei Dir) gemeinsam, die demux-Treiber, DMA-Completion-Worker? Hoffentlich finde ich hier erstens Zeit zum Debuggen, und zweites dann auch den Bug...

Hallo S:oren,
wie kann ich das mit nur einem aktivierten CPU Core, statt 4 CPU Cores nachstellen?

Zitat von Uwe

wie kann ich das mit nur einem aktivierten CPU Core, statt 4 CPU Cores nachstellen?

Am einfachsten so:

echo 0 > /sys/devices/system/cpu/cpu1/online
echo 0 > /sys/devices/system/cpu/cpu2/online
echo 0 > /sys/devices/system/cpu/cpu3/online

Ich schicke Dir per email nochmal 'was zum Testen...

Gruss,
S:oren

Hallo Phantom-ZXR,

hast Du noch die Möglichkeit, es mit einer alten Firmware zu testen? Konkret die FGPA 1.09 mit der 0.5.0, die 0.5.1 geht mit der 1.09 nicht.

Zitat von powarman

Konkret die FGPA 1.09 [...]

Kein Vertrauen in das 1.10er FPGA?
Aber im Ernst, unabhangige Tests sind immer gut! Schade, dass es hier keine Antwort gab.

Zitat von S:oren

Ich habe hier einen Patch in Arbeit, den ich ueber die Feiertage noch besser testen will.

Angehaengt ist hier ein saa716x-Treiberpatch, der besonders auf Multi-Core-Systemen die Wiedergabe etwas "geschmeidiger" macht.
powarman: Schaust Du Dir das mal an und uebernimmst es, wenn's passt?

Die eigentliche Loesung fuer meine kaputten Aufnahmen bringt aber dieser Kernel-Patch.

Gruss,
S:oren