Jump to content

Tonversatz / doch kein altes Problem


alex.ba

Recommended Posts

Ich habe gerade die Stelle im Custom EVR gefunden, die bei hoher GPU-Last (und vielleicht noch anderen Eventualitäten) Sync-Probleme verursacht, und dazu eine Änderung, die sie in Pro und GE beseitigt.

 

Allerdings muss ich das noch genauer analysieren und auch CiNcH zur Beurteilung vorlegen - so viel, wie er sich mit der Materie befasst hat, kennt er sich damit eindeutig am besten aus.

Link to comment

 

 

Ich habe gerade die Stelle im Custom EVR gefunden, die bei hoher GPU-Last (und vielleicht noch anderen Eventualitäten) Sync-Probleme verursacht, und dazu eine Änderung, die sie in Pro und GE beseitigt.

Ein Typischer Griga :-) Vielen Lieben Dank für deine Mühen. Da freu ich mich drauf.

 

VG Alex

Link to comment

 

Ein Typischer Griga :-) Vielen Lieben Dank für deine Mühen. Da freu ich mich drauf.

 

Das ist mit großer Wahrscheinlichkeit ein anderes Problem. Aktuelle Systeme sollten kein Problem haben, in Echtzeit zu rendern. Dann kommt das Problem nicht zum Tragen. Bei Griga müssen Frames verworfen werden, damit es sich wieder synchronisiert. Frame-Drops sind aber auch nicht toll, aber in diesem Fall, sprich wenn die GPU mit der Arbeit nicht nachkommt, die einzige Lösung.

Link to comment
Aktuelle Systeme sollten kein Problem haben, in Echtzeit zu rendern. Dann kommt das Problem nicht zum Tragen.

 

Ich bin noch nicht überzeugt davon, dass eine überforderte / zu langsame Ausgabe bei zu hoher GPU-Last die einzige mögliche Ursache ist. Jetzt denke ich erst mal eine Weile über die Sache nach...

 

Aber wohlgemerkt: Die HDMI/SPDIF-Passthrough-spezifischen Sync-Probleme werden damit nicht behandelt. Das ist eine andere Kiste... ;)

Link to comment

Aber wohlgemerkt: Die HDMI/SPDIF-Passthrough-spezifischen Sync-Probleme werden damit nicht behandelt. Das ist eine andere Kiste... ;)

 

Hmm wenn der Custom EVR bei Video nicht mehr hinterherkommt, Audio aber per bitstream ausgegeben wird, läuft doch Audio normal weiter und die Videodaten stauen sich... irgendwie... irgendwo... (Man sieht ich hab keine Ahnung :D )

 

Dann hat man doch den Audio drift bei Passthrough - nach meinem Verständnis - oder hat das wieder hinten und vorne nichts damit zu tun?

  • Like 1
Link to comment

So scheint es, wenn ich Griga richtig verstanden habe, praktisch zu sein mit der EVR Custom Implementierung, aber so sollte es nicht sein.

Dagegen hat man ja die Sync Algos.

Edited by nuts
Link to comment

Vielleicht sollte man zunächst mal die für mich manchmal pseudowissenschaftlich erscheinende diskussion auf die wesentlichen kausalen zusammenhänge beschränken.

 

Wenn ein dekoder/renderer mit dem live stream nicht mitkommt und hinterher hinkt, lässt es sich nur durch mehr power oder ressourcenschonende programmierung beheben.

 

Wenn hinter dem demultiplexer die einzelnen video- und audioströme auseinder driften, muss dafür gesorgt werden, dass alle durch eine gemeinsame zeitbasis synchronisiert und die zeitstempel (wegen fehlender pakete durch übertragungsfehler) fortlaufend berücksichtigt werden.

Link to comment

 

Wenn ein dekoder/renderer mit dem live stream nicht mitkommt und hinterher hinkt, lässt es sich nur durch mehr power oder ressourcenschonende programmierung beheben.

 

Der Grund für die höhere GPU Last mit EVR Custom Presenter dürfte der Zwischenschritt zum Mixen diverser Quellen (OSD) sein. Beim Standard EVR zeichnet bereits der integrierte Mixer, welcher dem Presenter vorgeschalten ist, in den Display BackBuffer. Der Presenter macht dann nur noch zeitlich gesteuert den Tausch des unsichtbaren BackBuffers mit dem sichtbaren FrontBuffer. Mit EVR Custom gibt es also quasi 2 Mixing Schritte. Griga könnte den 2. Mixing Schritt in der GE wegrationalisieren und auch direkt in den BackBuffer zeichnen lassen, weil er OSD über den EVR Mixer macht, mit dem Nachteil, dass man dann nur OSD hat, wenn auch Video läuft.

 

 

Hmm wenn der Custom EVR bei Video nicht mehr hinterherkommt, Audio aber per bitstream ausgegeben wird, läuft doch Audio normal weiter und die Videodaten stauen sich... irgendwie... irgendwo... (Man sieht ich hab keine Ahnung :D )

 

Dann hat man doch den Audio drift bei Passthrough - nach meinem Verständnis - oder hat das wieder hinten und vorne nichts damit zu tun?

 

Ihr könnt euch nun natürlich an diesen Strohalm klammern und hoffen, dass sich das Problem damit in Wohlgefallen auflöst. Ich glaube es noch nicht ;) .

Link to comment

..eine laienhafte frage ;) Mein Samsung i7, win7/64 zeigt im gerätemanager 2 graphikkarten an. Wo kann ich sehen, welche benutzt wird und mit welcher last die lauft? Ich habe mir dieses tool besorgt, aber da sehe ich keine GPU last.

Snap180.png

Snap181.png

Link to comment

..man antwortet sich immer am besten selbst :D

 

Anscheinend wird für das laptop display immer die integrierte grafikkarte verwendet. Aber auch dafür habe ich nun ein tool. Hier die (flüssige) 4k-wiedergabe von 19E, 10994H mit LAV Cyberlink ohne jedes weitere *custompipapo* ;)

Snap183.png

Link to comment

Mit 4K habe ich auch schon experimentiert. Die GPU Last mit dem aktuellen EVR Custom ist enorm. Das ist dem linearen D3D Sampler geschuldet. Nach Umstellung auf DXVA2 Scaling in der D3DTechDemo hat sich die GPU Last deutlich reduziert, weil bei Intel dafür ein dedizierter ASIC zum Einsatz kommt und GPU und CPU damit nicht belastet werden. Ganz zu schweigen davon, dass die Upscaling Qualität bei SD deutlich besser ist. Da kommt nämlich ein Lanczos4 mit Artefaktmaskierung zum Einsatz.

Link to comment

4k war nur ein test, um zu sehen, wie hoch die GPU-last geht. Bei normalem HD habe ich <15%. Mit custom evr sind es ca. 3-5% mehr als ohne. Die last kann also unmöglich die ursache sein. Custom scheint aber bei dem beispiel wie ein nadelöhr zu wirken, wodurch sich der videostrom zwängen muss. Sieht man an der erhöhten pufferzahl..

Link to comment

So, ich habe die Tage auch nochmal reichlich getestet. Wie ich bereits im Post #25 beschrieben hatte, geht bei mir der Ton nun dekodiert über HDMI raus und "Use DVB Clock" ist angehakt.

 

Damit habe ich mal 3,5 Std. KIKA HD laufen lassen (teilw. mit Kind vor dem Schirm :original: ) und danach die Eigenschaftsseite des DVB-Source-Filters aufgerufen. Der Clock-Drift lag da bei knapp -500ms und auch 2 Diskontinues waren auf dem Zähler - trotzdem alles synchron :laughing:. Am Sonntag dann das ganze F1-Rennen gesehen und dort sind sonst zum Rennende hin immer mal kurze Aussetzer, wie sie hier http://www.DVBViewer.tv/forum/topic/53870-live-tv-spdif-erfahrungsaustausch/?p=400817 beschrieben sind. Diesmal nix zu hören ! Das klappt also gut !

 

Nach der Diskussion mit Reclock habe ich mir gedacht, missbrauche ich den Renderer doch mal um am Ende der Ausgabekette Audio einfach wieder in AC3 encodiert auszugeben. Reclock sollte dabei nicht in die Syncronisation eingreifen, da diese ja schon durch den Source-Filter geregelt ist. Habe es aber nicht hinbekommen. Irgendwie erfolgt wohl immer eine Anpassung und das führt dann zu leicht schwankender Tonhöhe (so, als wenn jemand am Plattenspieler leicht bremmst !).

 

Es fehlt also im Prinzip nur einen Renderer mit Encodierfunktion. Dann bräuchte nicht der letzte Fließbandarbeiter (Reclock) die Fehler ausbügeln, die von den vorherigen Arbeitern (Source-Filter und Audiodecoder) übersehen werden! :glare: Den von Mediaportal auszukoppeln ist wohl nicht möglich, denke ich ?!?

  • Like 1
Link to comment

Im Grunde hast du gar nichts verstanden. ReClock ist ein Renderer mit Enkodierfunktion und macht genau das, was der MediaPortal Audio Renderer macht.

 

ReClock mit DVBSource und "Use DVB Clock" einzusetzen ist Schwachsinn.

Link to comment

@CiNcH:

 

Ich schätze "die meisten" deiner Beiträge ja sehr, weil sie in der Regel informativ sind. Die #136 hier gehört aber wohl eher in die Klospülung!

 

Mir zu unterstellen, dass ich nichts verstanden habe, ist ein wenig daneben. Ich versuche das Produkt DVBViewer zu verbessern. Darum teste ich mit. Das Reclock eine Lösung ist, habt ihr auf den vorherigen Seiten ja schon beschrieben. Habe ich auch verstanden und hätte das ganz easy nachstellen können. Nur ist Reclock ziemlich unfangreich zu konfigureren und nicht jeder Laie, der hier mitliest möchte sich zusätlich zu seinen Decodern und Splittern, die er evtl. schon auf dem System hat, noch damit rumschlagen. Zudem sagst du selbst, dass Reclock sich ungefragt einmischt, und empfielst in diesem Thread sogar die Deinstallation ! Die Postings muss ich jetzt wohl nicht erst raussuchen!?! Wenn man seinen PC auch (z.B.) zum Gamen benutzt, ist Reclock auf dem System eine super Fehlerquelle!

 

Mein Ansatz ist einfach der, hier bekannt zu machen, dass der DVBViewer mit seinen Hausmitteln ein lippensynchrones und ruckelfreies Bild liefern kann. Um die Fraktion der "Ich-sehe-das DolbyDigital-Lämpchen-am-Receiver-leuchten-Menschen" zu befriedigen, habe ich lediglich erwähnen wollen, dass es dann wohl eines Renderers bedarf, der den Ton wieder enkodiert.!

 

Aber das hast du beim lesen meines Postings wohl nicht verstanden. :thumbsdown:

  • Like 1
Link to comment

Ich habe meine Einstellungen mal gemäß der Empfehlung von cinch abgeändert und einen erneuten Test durchgeführt.

Da es keine Probleme gab mal meine Einstellungen als Bilder.

 

Konfig:

Sender: ZDF HD (H.264, AC3 Tonspur)

Win8 64bit

GPU: Intel Ivybridge (durchgehend hdmi Verbindungen, 50hz Ausgabe)

LAV Audio Decoder s. Screenshot

LAV Video Decoder (dxva2 aktiviert)

EVR Custom (VSync Aero aus)

Reclock Audio Renderer: s. Screenshot

DVBSource: s. Screenshot

AV Reciever: Marantz AV 7701 (DD Lämpchen leuchtet, HDMI Auto A/V Sync aus)

TV: Samung (keine besonderen Einstellungen)

post-39934-0-29782000-1406807319_thumb.png

post-39934-0-41266400-1406807326_thumb.png

post-39934-0-06128600-1406807336_thumb.png

post-39934-0-10537100-1406807344_thumb.png

post-39934-0-03283000-1406807352_thumb.png

Edited by nuts
Link to comment

 

Zudem sagst du selbst, dass Reclock sich ungefragt einmischt, und empfielst in diesem Thread sogar die Deinstallation ! Die Postings muss ich jetzt wohl nicht erst raussuchen!?!

 

Es geht darum, im Ausschlussverfahren den Schuldigen zu suchen. ReClock ist umfangreich zu konfigurieren, richtig, und mit den Standardeinstellungen waren meine Ergebnisse eher bescheiden, was nuts nun ja auch bestätigt hat. Einfachste Maßnahme ist, ReClock einfach mal zu deinstallieren und schauen, ob sich dadurch was ändert. Dann kann man mal versuchen mit der Konfiguration und dem integrierten Enkoder zu spielen.

 

 

dass es dann wohl eines Renderers bedarf, der den Ton wieder enkodiert.!

 

Und genau das ist ReClock. Ein Renderer ist der letzte Fließbandarbeiter in der Kette, wie du es so nett formuliert hast. In diese Kategorie fallen ReClock und der MediaPortal Audio Renderer gleichermaßen. Beide machen exakt dasselbe.

 

 

Dann bräuchte nicht der letzte Fließbandarbeiter (Reclock) die Fehler ausbügeln, die von den vorherigen Arbeitern (Source-Filter und Audiodecoder) übersehen werden!

 

Die können das Problem gar nicht sehen, geschweige denn automatisiert Gegenmaßnahmen ergreifen. Das Problem entsteht in der Regel erst bei der Ausgabe.

Link to comment

Stimme dir zu, nur würde ich Sourcefilter, Decoder und Videorenderer nicht so vorschnell aus der Verantwortungen entlassen (s. die von Griga untersuchten Punkte)

 

Die Settings liegen nun auf dem Tisch und ich bin gespannt auf Tests.

Sollte das wirklich helfen muss man sich mal überlegen wieso das so ist.

Link to comment

 

Stimme dir zu, nur würde ich Sourcefilter, Decoder und Videorenderer nicht so vorschnell aus der Verantwortungen entlassen (s. die von Griga untersuchten Punkte)

 

Stimmt, deshalb hatte ich in der Regel geschrieben. Der Frame-Scheduler im Custom EVR ist in der Tat problematisch und kann zu Asynchronität führen. Das war dazumal das erste, was ich neu geschrieben habe. Dennoch muss ein bisschen was zusammen kommen, dass es zu diesem Problem kommt. Die andere gemeinsame Variable hier ist Bitstreaming und das kann nachweislich und logisch nachvollziehbar zu Problemen führen.

 

 

Die Settings liegen nun auf dem Tisch und ich bin gespannt auf Tests.

Sollte das wirklich helfen muss man sich mal überlegen wieso das so ist.

 

Wenn man im ReClock Manual die "Sound pre-buffer size" nachschlägt, findet man dort, dass die Wiedergabe erst startet, wenn dieser Puffer gefüllt ist. Die Latenz im DVBSource sollte also IMHO mindestens der Pre-Buffer Größe in ReClock entsprechen, was standardmäßig nicht der Fall ist. Bei einer kleinen Source Filter Latenz dürften die Puffer in den Filtern immer einen niedrigen Füllstand haben. Eine Vergrößerung der Latenz im DVBSource oder Verkleinerung des Buffers in ReClock stellen sicher, dass der Puffer voll ist, bevor die Ausgabe starten soll.

File orientierte Splitter à la LAV oder Haali dürften da höhere Latenzen fahren. Bei File ist es egal, ob die Wiedergabe eine Sekunde später startet.

Link to comment

Die andere gemeinsame Variable hier ist Bitstreaming und das kann nachweislich und logisch nachvollziehbar zu Problemen führen.

Habe den Test mit den oben genannten Einstellungen jetzt einfach mal laufen lassen (ab 11:00 Uhr) und immernoch kein ASync oder Pufferüberlauf.

Das ist schonmal sehr schön, auch die erneute Einarbeitung in Reclock hat das Wissen von früher wieder aufgefrischt und mit WASAPI PCM Ausgabe wollte ich mich sowieso nochmal auseinandersetzen.

 

Die Gesichte mit dem unterschiedlichen Taktgebern in PC / externer Decoder glaube ich, auch aufgrund des >6Stunden Tests, in der Form jetzt mal nicht.

Ich kann der Argumentation zwar Folgen, aber es gibt keine Hinweise das solche Probleme real existieren (bzw. nicht behandelt werden).

Weder mit PC noch mit anderen Zuspielern!

Link to comment

Ich meine jetzt nicht nur den Drift, sondern auch den von dir beschriebenen durch diverse externe Geräte provozierten latenzbedingten Versatz, sprich die Konstante, die man in vielen Dekoder-Filtern ausgleichen kann.

Link to comment

Ok die kann es natürlich geben und gibt es auch.

Danke der Einstellungen in Decoder, Zuspieler, AV Receiver ist das eher unproblematisch.

 

In diesesm Sinne warten wir mal auf weitere Berichte. ;)

Link to comment

@nuts

Gehe ich richtig in der Annahme dass die Latency Einstellung im DVBViewer Filter bei dir keinen direkten Einfluss auf den Tonversatz hat?

Bei Passthrough gab es definitiv schon Meldungen wo dass sofort einen merkbaren Einfluss hat. Also der Latency Wert hat 1:1 den Ton verschoben.

Link to comment

Nee hat keinen Einfluss sobald die PTS Latenz ausreichend groß ist (in Abstimmung mit dem Puffer im Audiorenderer).
Bei zu kleinem Wert ist der A/V Sync sofort weg, aber dagegen können wir nichts tun.

Das betrifft aber imho nur Custom Audiorenderer die für Dateiwiedergabe ausgelegt sind und viel puffern.

Edited by nuts
Link to comment

 

Die Gesichte mit dem unterschiedlichen Taktgebern in PC / externer Decoder glaube ich, auch aufgrund des >6Stunden Tests, in der Form jetzt mal nicht.

Ich kann der Argumentation zwar Folgen, aber es gibt keine Hinweise das solche Probleme real existieren (bzw. nicht behandelt werden).

Weder mit PC noch mit anderen Zuspielern!

 

Nur noch kurz dazu... Beim Intel 23.976 Hz Problem kann man sehen, was eine krumme Clock bewirken kann. Da passiert alle ~4 Minuten ein Bildüberlauf, was bei 23.976fps 41.7ms entspricht. Bei spätestens 3 Überläufen (12 Minuten) würdest du die Asynchronität merken, wenn da keiner synchronisierenderweise eingreifen würde.

Link to comment

Darum ruckelt es bei krummer Uhr (verworfene oder wiederholte Orginalframes = Sync Algo)

A/V Sync bleibt aber erhalten.

 

Am 60hz Laptop läuft Auido und Video ja auch nicht auseinander bei 50hz Quellen.

Die Thematik ist übrigens ein sehr gutes Argument für madVR. :)

Link to comment

 

Darum ruckelt es bei krummer Uhr (verworfene oder wiederholte Orginalframes = Sync Algo)

A/V Sync bleibt aber erhalten.

 

Das kommt drauf an auf was du synchronisierst. Wenn du auf eine auf die GPU Ausgabe synchronisierte Clock synchronisieren würdest ohne die Audio-Frequenz anzupassen, würde es mit dem oben erwähnten Tempo auseinander laufen. Das passiert aber zum Glück nicht, weil ReClock entsprechend eingreift. Mit DirectSound Audio Renderer wird auf Basis der Audio Clock synchronisiert. Dann hat man die von dir angesprochenen Video Hüpfer. Was ich damit sagen will ist, dass so eine krumme Clock unter Umständen auch in einem externen Verstärker stecken könnte. Auch dann laufen A/V auseinander und man hätte keine Chance da was zu synchronisieren.

Link to comment

Das ist richtig und alles schon vorgekommen.

z.B. hatte Onkyo vor einigen Jahren einen schlauen Videochip in ihren AV Receivern verbaut, der aus 23,976hz Signalen mal ganz elegant 24hz machte.

Resultat waren Ruckler, aber je nach Sync und wo die krumme Uhr sitzt kann es auch Audio oder A/V Sync betreffen.

 

Diese Sachen würde ich aber mal gern für die Diskussionen herausnehmen.

Dagegen lässt sich nichts tun und solche Problem sind meist auch bekannt.

Die HiFi Szene ist bei weitem nicht so leidensfähig wie die HTPC'ler. :D

Link to comment

Noch ein Szenario...

 

Die "DVB Clock" ist krumm. Das kann man mit dem DVBSource sogar simulieren, soweit ich weiß. Griga hat mal einen Mechanismus eingebaut, mit dem man die Clock schneller und langsamer machen kann. Was passiert nun?

 

> Video hat ruckler, weil der VSync auf einer nicht zur DVB Clock synchronisierten Clock basiert

 

> PCM Audio mit DirectSound (Slave Modus): Audio wird durch Frequenz/Pitch Änderung auf die DVB Clock synchronisiert (siehe DirectSound Eigenschaftsseite)

> Bitstream Audio mit DirectSound: keine Anpassung möglich, Audio driftet ab

 

 

So, jetzt geb ich Ruhe.

 

 

Probiert nuts' Einstellungen!

Link to comment

Eine endlose geschichte..

 

Zumindest der Custom EVR gehört in die tonne. Ich brauch den zum glück nicht, genauso wenig wie den VOD :innocent:

Link to comment
  • 5 weeks later...

Ich habe meine Einstellungen mal gemäß der Empfehlung von cinch abgeändert und einen erneuten Test durchgeführt.

Da es keine Probleme gab mal meine Einstellungen als Bilder.

 

Konfig:

Sender: ZDF HD (H.264, AC3 Tonspur)

Win8 64bit

GPU: Intel Ivybridge (durchgehend hdmi Verbindungen, 50hz Ausgabe)

LAV Audio Decoder s. Screenshot

LAV Video Decoder (dxva2 aktiviert)

EVR Custom (VSync Aero aus)

Reclock Audio Renderer: s. Screenshot

DVBSource: s. Screenshot

AV Reciever: Marantz AV 7701 (DD Lämpchen leuchtet, HDMI Auto A/V Sync aus)

TV: Samung (keine besonderen Einstellungen)

Bin jetzt endlich mal zum Testen gekommen.

 

Im Gegensatz zu Dir gebe ich den Ton allerdings nicht per HDMI an einen Verstärker weiter sondern per SPDIF. Dementsprechend habe ich in Reclock bei Devices to use with DirectSound statt dem Primären Soundtreiber den SPDIF Treiber ausgewählt. Das Ganze auf AudioB gelegt, da AudioA bei mir der Fernseher ist. Aktuelle Version von Reclock und den LAV Filtern.

 

DVD:

 

Als Audio- und Video-Decoder LAV. Bild und Ton sind nach 45 Minuten immer noch synchron. Was allerdings blöd ist: direkt nach dem Starten des Films kommt ein Popup-Fenster mit dem Titel "DVBViewer" und der Meldung "Gleitkommadivision durch Null". Vermutlich bei Umschaltung auf AudioB mit dem Reclock Renderer.

 

BLURAY:

 

Als Audio-Decoder LAV, als Video-Decoder PowerDVD 10. Bild und Ton nach 90 Minuten "Tribute von Panem" immer noch synchron. Bildfrequenz = 24 Hz. Fehlermeldung "Gleitkommadivision durch Null" kommt auch bei BLURAY Wiedergabe. Die Fehlermeldung kommt direkt nach dem Umschalten von AudioA auf AudioB, also dann wenn wohl Reclock aktiviert wird(?)

 

TV HD mit AC3-Ton:

 

Bild/Ton synchron über längere Zeit. Problem bei AC3 2.0: alle paar Sekunden ist der Ton abgehackt. Bei 5.1 kein Problem.

 

Wiedergabe HD Aufnahme mit AC3-Ton:

 

To be tested

 

 

Updates folgen, sobald ich getestet habe.

Edited by dbraner
Link to comment
  • 2 weeks later...

Hallo zusammen,

 

ich muss auch mal wieder meinen Senf dazugeben.

 

Meine letzte Erfahrung mit schleichender Asynchronität hatte ich mit meinem Acer RL100, dort lag es daran, dass die Nvidia-Treiber, die ich für die ION2 des RL100 installiert hatte, zu neu waren. Neuer Treiber: Bild + Ton nach wenigen Minuten asynchron. Alter Treiber (259.irgendwas) drauf: Alles prima.

 

Nun hat mein HTPC einige Evolutionsstufen hinter sich, die letzte Erweiterung war eine neue Grafikkarte, um mit dem Rechner auch noch ein wenig daddeln zu können.

 

Seit ich jedoch meine GTX750 von NVidia im System habe, ist das Thema Asynchronität wieder aktuell. Jedoch schleicht hier nichts mehr, sondern die Asynchronität ist plötzlich da. Angebunden ist der Rechner via HDMI.

 

Dazu folgende Beobachtungen:

PC läuft mit laufendem DVBViewer >3h, TV so lange aus. TV wieder an: Alles super synchron.

PC mit laufendem DVBViewer, massive Umschaltorgien, Timeshift und Aufnahmen ansehen - Ton hinkt dem Bild hinterher. Bevor wir jetzt irgendwelche Filtergraphen analysieren: Selbst nach dem Beenden und Neustart des DVBviewers bleibt der Ton asynchron! Und: Auch ein in WMP abgespieltes Video ist jetzt plötzlich asynchron! Ein kurzes deaktivieren und aktivieren des HD-Audio-Treibers bewirkt nun wieder Synchronität in allen Programmen! Frage in den Raum: Das HDMI-Kabel ist eines der preiswerteren, kann es vielleicht die Ursache des Verhaltens sein? Ansonsten würde ich mal sagen, dass NVidia irgendwelche Krampen in die aktuellen Treiber gebaut hat.

 

Viele Grüße

elch

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...