Tonversatz / doch kein altes Problem

[alex.ba]

Hallo,

 

also nachdem ich eigentlich wieder ganz positiv gestimmt war muss ich nach der Aussage von Griga sagen dass ich das überhaupt nicht mehr bin. Ich finde es zwar super dass hier weiter an dem sehr interesanten SAT>IP gearbeitet wird und auch Möglichkeiten geschaffen werden auf einfache Weise mit einem zentralen Server und einem einfachen CLIENT (in Form eines TVs) TV wiederzugeben. Das Thema Live-TV Wiedergabe auf einem HTPC wurde aber damit (zumindest für mich) gänzlich uninteresant wenn solche Probleme nicht behandelt werden (bzw. gar nicht behandelbar sind).

 

Grüße Alex

[Griga]

Tut mir leid. Aber es ist einfach so: Wenn man Video und Audio in getrennte Streams zerlegt (demultiplext), dekodiert und dann noch zwecks Wiedergabe auf verschiedene Geräte verteilt, sind Sync-Probleme ziemlich wahrscheinlich.

 

Funktionieren kann es nur, wenn das Audio-Ausgabegerät dem PC eine seiner Wiedergabegeschwindigkeit entsprechende Uhr liefert (die eine Richtung) und andererseits jedes Ausgabegerät die DirectShow-Zeitstempel empfängt, die auf die Millisekunde genau den Wiedergabezeitpunkt bestimmen, und sich danach richtet (die andere Richtung). Die Annahme, dass die verwendeten Schnittstellen, Treiber und Endgeräte dies leisten, wäre höchst optimistisch, mal vorsichtig ausgedrückt.

[alex.ba]

Hallo Griga,

 

ok soweit verstanden ... aber das ist es doch was jeder x-beliebige Receiver bereits heute tut oder?. Wenn man AUdio Video per HDMI ausgibt dann OK aber jeder Receiver hat doch auch die Möglichkeit den Top per SPDIF oder analog auszugeben. Oder muss ich mir das so vorstellen dass dies bei fertigen Boxen einfach so aufeinader abgestimmt ist dass es trotzdem funktioniert.

 

Versteh es bitte nicht falsch. Ich nutze das Produkt seit Jahren und bin ja auch zufrieden. Ich will nur verstehen ob das ein HTPC-TV, ein DVBViewer oder sonst irgendetwas anderes ist.

 

Viele Grüße

 

Alex

[Derrick]

 

Ich denke, die beste Möglichkeit, Sync-Problemen beim Transfer von Video/Audio auf externe Geräte zu vermeiden, besteht darin, auf dem PC z.B. einen SAT>IP-Server laufen zu lassen, und dazu einen netzwerkfähigen Fernseher als SAT>IP Client, der den empfangenen Transportstream selbst demultiplext und dekodiert. Diese von SES Astra eingeführte Technik ist noch recht neu, wird aber zunehmend von diversen Firmen unterstützt. Inzwischen ist auch eine Spezifikation für DVB-C in der Pipeline. Auch hier wird intensiv daran gearbeitet, diese Möglichkeit brauchbar & zuverlässig zu implementieren. IMO lohnt das eher, als sich in ein programmtechnisch höchst problematisches Minenfeld zu begeben, in dem - wenn überhaupt - nur wackelige Teilerfolge zu erzielen sind.

.

Damit ist der DVBViewer/RS aber eigentlich überflüssig

[Tjod]

... aber das ist es doch was jeder x-beliebige Receiver bereits heute tut oder?

Auf wie vielen von denen Läuft Windows und dient das DirectShow System als Grundlage? Ich glaube auf keinem.

 

Das ist aber die Basis auf der der DVBViewer aufbaut. Und mit deren Limitierungen wir hier leben müssen.

Eine komplett eigene Basis aufzubauen ist mit den Ressourcen hier illusorisch.

 

Wenn man Audio Video per HDMI ausgibt dann OK aber jeder Receiver hat doch auch die Möglichkeit den Top per SPDIF oder analog auszugeben.

Da wird ziemlich sich das Audio Signal nicht so durchgereicht wie es vom Sender kommt.

(Wo es ja nach Sender und teilweise sogar Sendung einen leicht anderen Versatz dazwischen gibt wie Audio und Video ankommen. Und die Syncronisation nur über den jeweils enthaltenen Zeitstempel erfolgt).

 

Sondern Video und Audio werden im Receiver Synchron zu allen Ausgängen raus geschickt (wie oben von mir schon beschrieben). Das lässt sich bei einer Spezialisierte Hardware/Software kombination die genau für einen Zweck entwickelt wurde deutlich leichter realisieren als mit einem PC. Der zwar für alles eingesetzt werden kann. Aber auf so was nicht wirklich optimiert ist.

[Griga]

Ich habe jetzt mal etwas im Web recherchiert, insbesondere weil mir nicht klar war, wie HDMI in der Hinsicht tickt. Und mir erstaunt die Augen gerieben : AV Sync-Probleme scheinen ein ziemlich häufiges Phänomen zu sein, bei allen möglichen Geräten.

 

Als Kind des analogen Zeitalters kenne ich sowas überhaupt nicht. Auch jetzt ist meine antiquierte Consumer-Elektonik noch durchweg per Scart oder Cinch verbunden. Sync-Probleme? Nie erlebt. Weder jetzt mit dem DVD-Player, noch früher mit dem Video-Cassettenrecorder. Bild auf dem Fernseher und Ton über die Stereo-Anlage? Egal ob vom PC oder vom Receiver: Der Sync ist perfekt. Und ich finde mal wieder mein Misstrauen gegen diesen neumodischen Kram bestätigt. Digitale Qualität und so...

 

Auch bei dem reinen DVBViewer-Desktop-Betrieb, den ich hier meistens pflege - schlicht mit Onboard-Sound und Chipsatz-Grafik - erlebe ich so gut wie nie AV Sync-Probleme, mit einer Ausnahme: Gelegentlich bei Verwendung der LAV Filter, wenn es Aussetzer im Datenstrom gibt, wie bereits berichtet. Ich habe deshalb den LAV Audiodecoder probeweise durch ffdshow ersetzt und schaue mir an, wie das ausgeht. Bislang gut, aber das heißt noch nichts - sowas erfordert Langzeit-Versuche.

 

Zurück zu HDMI: Wenn ein Gerät Video/Audio synchron über HDMI ausgibt, heißt das noch lange nicht, dass es synchron wiedergegeben wird. Ursache für AV Sync-Probleme ist meistens eine unterschiedliche Verarbeitungszeit von Video und Audio. Video dauert i.a. länger, z.B. wegen diesen tollen Bild-Aufhübsch-Funktionen. Bessere Geräte bieten deshalb in den Tiefen ihrer Menüs die Möglichkeit, Audio-Verzögerungen vorzugeben, um das nach Augenschein/Gehör auszugleichen. Noch bessere Geräte sogar pro Eingang/Ausgang, weil das je nach Quelle/Ziel verschieden aussehen kann. Was Anwendern heutzutage alles zugemutet wird...

 

Ab HDMI 1.3 gibt es sogar eine Art Auto-Sync. Der Fernseher meldet der Quelle beim Handshake die vorraussichtliche Differenz zwischen Video- und Audioverarbeitung, und der Receiver oder was auch immer sorgt dann für die erforderliche Verzögerung (wobei man sich fragt: Warum macht es der dösige Fernseher nicht gleich selbst?). Manchmal scheint das sogar zu funktionieren. Wie auch immer: PC-Anwendungen haben so gut wie nichts mit diesem HDMI-Zirkus zu tun. Das ist alles in Treibern gekapselt.

 

Allerdings geht es bei den in zahlreichen Internet-Foren beklagten Problemen fast durchweg um einen konstanten Versatz zwischen Video und Audio. Dafür könnte ich im DVBViewer Filter eine Korrekturmöglichkeit ergänzen, aber es lässt sich bereits jetzt schon auf der Eigenschaftsseite des AC3 Filters ausgleichen, die dafür einen Schieberegler bietet.

 

Ein mit der Zeit immer größer werdender Versatz zwischen Video und Audio ist allerdings eine andere Geschichte und in der Tat ein wirklich unangenehmes Problem. Bei Reports wie

 

Da kuckt man Fussball und zur Halbzeit sieht man dann in den Nachrichten das Bild und Ton fast 5 sekunden auseinander laufen

 

stellen sich mir verschiedene Fragen:

 

- Warum berichtet niemand in solchen Fällen, ob Video oder Audio verzögert ist? Daraus könnte man zumindest gewisse Schlüsse ziehen.

 

- Wo bleiben die um 5 Sekunden verzögerten Video- oder Audio-Daten so lange? Insbesondere 5 Sekunden Video sind kein Pappenstiel, da muss irgendein Puffer schon ganz schön vollgelaufen sein. Im DVBViewer Filter treffen zusammengehörige Video- und Audiodaten zwar nicht exakt gleichzeitig ein, weil auch die Sender eine längere Video-Verarbeitungszeit berücksichtigen und deshalb Video einen gewissen Vorsprung geben. Aber die Differenz beträgt nicht 5 Sekunden, sondern vielleicht 1 Sekunde (bei H.264) oder 200 ms (bei MPEG2) - wer es genau wissen will, schaut sich die originalen DVB-Zeitstempel (PTS) auf der Eigenschaftsseite des DVBViewer Filters an. Mehr dazu im Abschnitt Wiedergabetakt / Zeitstempel der Anleitung.

 

- Wo werden die vom DVBViewer Filter weitergereichten Zeitstempel ignoriert? Ein eventueller Versatz beim Eintreffen von Video und Audio-Daten an welcher Stelle auch immer sollte überhaupt keine Rolle spielen, solange dadurch nicht Zeitstempel in der Vergangenheit liegen, so dass der Zeitpunkt der Wiedergabe bereits verstrichen ist, oder soweit in der Zukunft, dass dadurch Pufferkapazitäten überschritten werden. Es ist Aufgabe der Renderer, Daten so lange zu puffern, bis sie laut Zeitstempel mit der Wiedergabe dran sind. Auch Diskontinuitäten im Datenstrom sollten darauf keinen Einfluss haben - die Zeitstempel werden von den Sendern vorgegeben und können nicht mal eben an eine andere Stelle rutschen.

 

Allerdings sind die Zeitstempel ab dem DVBViewer Filter nicht mehr fester Bestandteil der Video/Audiodaten, sondern werden begleitend zu den Datenlieferungen (Samples) separat weitergereicht. Und durchlaufen dabei die Decoder - eventuell könnte da also etwas aus dem Ruder laufen. Deshalb ist das einzig Produktive, was mir im Moment einfällt, dem LAV-Autor das selbst erlebte Problem (siehe oben) zu schildern und zu fragen, wie eigentlich die Zeitstempel in den Decodern behandelt werden. Sollte sich daraus etwas ergeben, werde ich hier berichten...

[nuts]

Das Problem ist wirklich der A/V Drift.

Einen konstanten Versatz bekommt man in den Griff!

Das Problem lässt sich leider nicht vernünftig einkreisen, aber ich bin schon der Meinung, dass wir einen Oder mehreren Faktoren noch nicht richtig auf dem Schirm haben (ich weiß auch nicht welche, Ergebnisse sind ja leider auch stark unterschiedlich).

 

Das "alte" Problem mit den unterschiedlichen Taktgeber führte immer zu Rucklern aber nicht zur einem A/V Drift!

So entstand dann Reclock um die Audio Abspielgeschwindigkeit mit dem VSync zu synchronisieren.

[Tjod]

Ich habe das Gefühl das immer noch nicht allen klar ist das hier über zwei komplett verschiedene Probleme geredet wird.

Da die Ursachen und die möglichen Lösungen verschieden sind.

 

Wenn es um einen Versatz beim Ton geht muss die erste Frage eigentlich immer lauten:

"Wird S/PDIF/HDMI-Passthrough verwendet?"

http://de.wikipedia.org/wiki/Sony/Philips_Digital_Interface#Mehrkanalton

 

1). Der Ton wird auf dem PC decodiert.

Da kommt es in der regle wenn nur zu einem Konstanten Versatz.

Die Lautstärke lässt sich im DVBViewer ändern.

Die Latency Einstellung im DVBViewer Filter hat keinen Einfluss auf den Tonversatz.

 

2). Via Passthrough wird das Audiosignal noch codiert an den Fernseher/Receiver weitergeleitet und der kümmert sich um die gesamte Verarbeitung des Audiosignals.

Der Versatz wächst über die Zeit häufig an.

Die Lautstärke lässt sich im DVBViewer nicht ändern. Höchsten Sturmschalten funktioniert (aber nicht über den DVBViewer sondern nur direkt in Windows).

Die Latency Einstellung im DVBViewer Filter führt häufig direkt zu einem Tonversatz (höherer Wert = größerer Versatz).

[Tjod]

Das "alte" Problem mit den unterschiedlichen Taktgeber führte immer zu Rucklern aber nicht zur einem A/V Drift!

Die Ruckler bei unterschiedlichen Taktgeber sind das Resultat der A/V Drift.

Die Drift wird halt nur nie größer, weil irgend was dennoch eine gewisse Synchronizität erzwingt.

z.B. weil Puffer gleich schnell befüllt werden aber einer zu langsam gelehrt wird und dann der andere irgendwann überläuft.

 

Und Lösungen wie Reclock, die die Taktgeber Synchronisieren, sind halt schlecht möglich wenn der eine Taktgeber für Video im PC ist. Und der für Audio im Receiver oder im Fernseher.

[nuts]

Naja irgendwo schon aber auch nicht wirklich.

Die Ruckler entstehen, da VSync und Directshow Uhr (abgeleitet von Zeitstempel und Audio Uhr) auseinanderlaufen und dann Video Bilder verworfen oder wiederholt werde (das ist die Sync.).

 

Bild und Ton läuft dabei aber nicht (wesentlich) auseinander.

[dbraner]

Meine aussage waren Theoretische Überlegungen. Meines Wissens abarbeitet beim DVBViewer derzeit niemand an einem eigenen Audiorenderer der so was eventuell erlauben könnte (und ob das unter Windows mit annehmbarem aufwand wirklich möglich wäre steht noch auf einem anderen Blatt).

 

Ob sich so was eventuell auch mit existierenden Audiorenderer und Decodern realisieren lässt weiß ich nicht.

 

Zumindest bei Mediaportal wurde das Problem wohl mit einem eigenen Audiorenderer gelöst.

 

Mein "Pain Point" ist auch eindeutig der anwachsende Versatz, nicht der konstante.

[CiNcH]

 

Zumindest bei Mediaportal wurde das Problem wohl mit einem eigenen Audiorenderer gelöst.

 

Ich sehe dafür keine Anhaltspunkte. Wie ich das verstehe, ist das nichts anderes als ein ReClock Nachbau. Für Bitstream Ausgabe haben die auch keine Lösung.

[nuts]

Ja anders geht das nach meinem Verständnis auf der Audioseite auch gar nicht.

 

Mir ist der A/V Drift trotzdem ein Rätsel.

Keine Ahnung wo der entsteht.

Man müsste das mal genau analysieren.

Aufnahme vs LiveTV

EVR Custom Aero on vs Aero off

DVB Clock aus vs ein

Diverse Decoder

 

Usw.

Edited July 24, 2014 by nuts

[CiNcH]

 

Aufnahme vs LiveTV

EVR Custom Aero on vs Aero off

DVB Clock aus vs ein

Diverse Decoder

 

ReClock mal deinstallieren... ich traue der Geschichte nicht. Sobald ReClock installiert ist, wird die ReClockDS.dll geladen anstatt quartz.dll, egal was für ReClock konfiguriert ist.

[VinoRosso]

Mal ne Zwischenfrage:

 

Hat die Option "Use DVB Clock" irgendeine Auswirkung wenn man Passthrough über HDMI benutzt?

 

Oder greift die nur bei PCM Ausgabe?

[CiNcH]

 

Hat die Option "Use DVB Clock" irgendeine Auswirkung wenn man Passthrough über HDMI benutzt?

 

"Use DVB Clock" ist bei Passthrough kontraproduktiv und proviziert den Async. Der Graph und Video laufen dann mit der DVB Clock, der Audio Bitstream mit der Audio Clock. Bei Passthrough sollte man die Audio Clock verwenden und hoffen, dass Erzeugeruhr und Audio Clock so genau wie möglich sind und so wenig wie möglich voneinander driften, damit es zu keinem Puffer Über- oder Unterlauf kommt und Video so selten wie möglich dem VSync nachgeregelt werden muss.

[dbraner]

 

Ich sehe dafür keine Anhaltspunkte. Wie ich das verstehe, ist das nichts anderes als ein ReClock Nachbau. Für Bitstream Ausgabe haben die auch keine Lösung.

 

Das liest sich in der Beschreibung aber anders (siehe hier http://wiki.team-mediaportal.com/1_MEDIAPORTAL_1/141_Configuration/MediaPortal_Configuration/9_Codecs_and_Renderer/3_MP_Audio_Renderer_(MPAR)):

 

The MediaPortal Audio Renderer

A. Solve the refresh rate - frames per second mismatch

The MediaPortal Audio Renderer is able to increase or decrease the playback speed of the video to make the videos FPS match the display refresh rate or its whole number multiplier.

B. Solve Audio / Video clock drifting

The MediaPortal Audio renderer adjusts the reference clock a bit and resamples the audio to match the result.

C. DTS and DolbyDigital audio formats:

1. Microsoft DTV DVD Audio codec

   The Microsoft DTV DVD Audio codec will not send the audio to any other renderer except the Mircrosoft DirectSound Renderer. This is not a technical limitation, but a license restriction from Dolby Labs. This means that you cannot use the Microsoft DTV DVD Audio codec together with the MP Audio Renderer (http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx). But there are plenty of alternatives.

2. bit streaming: input

   Since the MediaPortal Audio Renderer must adjust the reference clock, the audio itself has to be processed. However, it is impossible to process an encoded audio stream. That's why the audio data must be decoded before it can be processed. This must be done by the audio codec. If you use the MPC-MPA codec, then you have to go to the codec configuration inside MediaPortal and set it to "decode to speakers" for DTS and DolbyDigital. For ffdshow audio decoder the same can be done by disabling all passthru related options in output settings.

3. Multichannel support for SPDIF

   The MediaPortal Audio Renderer is able to encode the audio again to AC3, so you can output the processed audio through SPDIF to your receiver as a Dolby Digital

[nuts]

Da steht doch genau das was von Cinch und mir vermutet wurde.

[CiNcH]

 

Da steht doch genau das was von Cinch und mir vermutet wurde.

 

Richtig. Genau diese Seite war auch der Ausgangspunkt meiner Aussage.

[nuts]

Anyway ... Lässt sich der MP Audiorenderer in anderen Anwendungen verwenden?

[CiNcH]

So wie es aussieht, enkodiert der MP Audio Renderer den Bitstream neu mit einer anderen Clock, die sich wie ReClock auf die Refresh Rate bzw. den VSync synchronisiert. Wenn man im DVBViewer die Audio Clock im Graph verwendet (nicht die DVB Clock), muss man das nicht. Audio und Video sind dann perfekt synchron, allerdings läuft der VSync auf einer anderen Clock, weshalb ab und zu ein Frame wiederholt oder verworfen werden muss (ab und zu ein Ruckler).

 

ReClock implementierte früher nur einen Algorithmus, der AC3 Frames verwirft oder wiederholt, was sehr gut hörbar war/ist. Mittlerweile kann der aber doch auch neu kodieren?

 

Was bei der MP bzw. ReClock Methode aber nicht berücksichtigt wird bzw. nicht berücksichtigt werden kann ist, dass wenn man Bitstream ausgibt, die Audio Dekodierung und Ausgabe von einem externen Gerät und somit doch wieder von einer anderen Clock gemacht wird, die ebenfalls nicht synchron mit der PC-Uhr läuft. Sprich auch dann ist man nicht geschützt davor, dass Audio und Video auseinander laufen. Evtl. ist die Uhr in dem Gerät komplett krumm...

 

Ich gebe deshalb schon seit Ewigkeiten analog aus. Ein PC dekodiert Audio mittlerweile, ohne sich dabei an den Eiern zu kratzen. Was verspricht man sich von einem externen Gerät? Einen 0.1 dB höheren SNR, weil die Interferenzen evtl. weniger sind? Superteure Hardware für Audiophile?

[nuts]

Analoge Ausgabe? Jetzt wird es aber wild ...

Die meisten AV Receiver haben gar keinen analogen Mehrkanal Eingang mehr!

 

Das Problem mit dem externen Geräten führt meiner Meinung nach nicht zu einem Drift, sonder zu einem konstanten Versatz.

Edited July 24, 2014 by nuts

[CiNcH]

Das Problem mit dem externen Geräten führt meiner Meinung nach nicht zu einem Drift, sonder zu einem konstanten Versatz.

 

Konstant ist der nicht. Man hat den latenzbedingten Versatz und dann kommt noch ein Drift dazu.

[ThulsaDoom]

..., weshalb ab und zu ein Frame wiederholt oder verworfen werden muss (ab und zu ein Ruckler).

 

Sicher, das dort Videoframes verworfen oder verdoppelt werden und nicht Audioframes, denn ich bemerke in dieser Konstellation immer ganz kurze Audiodropouts (nach ca. 60-70 min.)...oder ist das ein Pufferüberlauf des DVB-Sourcefilters ??? Kann auch sein !?!

 

Videoruckler fallen mir gar nicht mehr auf ! Un da bin ich nach all den Jahren sehr geschult mit meinem Auge !

[nuts]

 

Konstant ist der nicht. Man hat den latenzbedingten Versatz und dann kommt noch ein Drift dazu.

Das Problem haben dann aber alle Geräte (Receiver, DVD Player). Woher soll eigentlich der Drift kommen?

[ThulsaDoom]

Analoge Ausgabe? Jetzt wird es aber wild ...

Die meisten AV Receiver haben gar keinen analogen Mehrkanal Eingang mehr!

 

Denke auch, ein decodieren reicht ...hatte ich ja bereits im vorherigen Post geschrieben...analoge Ausgabe ist dann doch etwas zu viel verkabelung

[CiNcH]

 

Woher soll eigentlich der Drift kommen?

 

Weil das externe Gerät Audio mit einer anderen Clock dekodiert und ausgibt als der PC das Video. Außer evtl. das Gerät kann anhand des Puffervöllegrads einwirken...

 

 

Sicher, das dort Videoframes verworfen oder verdoppelt werden und nicht Audioframes, denn ich bemerke in dieser Konstellation immer ganz kurze Audiodropouts (nach ca. 60-70 min.)...oder ist das ein Pufferüberlauf des DVB-Sourcefilters ??? Kann auch sein !?!

 

Das passiert unter den folgenden Umständen...

 

Im Graph wird die DVB Clock verwendet. Somit verwendet die Wiedergabe (der Graph) die DVB Clock, die Audio-Ausgabe die Audio-Clock. Jetzt kommt es früher oder später auf Grund des Clock-Drifts zu Pufferproblemen im Audio-Renderer.

[CiNcH]

 

Das Problem haben dann aber alle Geräte (Receiver, DVD Player).

 

So wie ich Griga verstanden habe, hat er genau das bei seiner Recherche auch festgestellt. Es hängt halt auch von den PC-Komponenten und den Geräten ab und wie genau deren Uhren sind. Je genauer, desto weniger der Drift und desto später merkt man, dass da was aus dem Ruder läuft.

[nuts]

Die Recherche ergab imho einen konstanten Versatz aufgrund unterschiedlicher Processing Zeiten. Das lässt sich gut in den Griff kriege (dafür gibt es auch den Auto sync ab HDMI x.y).

 

Fies ist der Drift und der dürfte nicht ursächlich an der externen Decodierung liegen.

[Tjod]

Fies ist der Drift und der dürfte nicht ursächlich an der externen Decodierung liegen.

Und wie wird deiner Meinung nach sichergestellt dass der Taktgeber in Gerät A wo das Video Decodiert wird und der Taktgeber in Gerät B gleich schnell laufen und nicht mit der Zeit auseinander Driften?

[nuts]

Ihr überschätzt das meiner Meinung nach.

Der Unterschied durch einen anderen Taktgebern ist konstant und nicht sehr hoch.

Decodiert wird Video auch im PC (Directshow Uhr)

 

Problematisch ist das nur im Zusammenhang mit dem VSync (im PC).

[Tjod]

Der Unterschied durch einen anderen Taktgebern ist konstant und nicht sehr hoch.

Das hängt von der Qualität der Taktgeber ab. Beim Vergleich Soundkarte / DVB Takt gab es ja schon teilweise merklich unterscheide. Sonst hätte es ja die DVB Clock Geschichte nie gegeben.

 

Decodiert wird Video auch im PC (Directshow Uhr)

Das Audiosignal aber nicht.

 

Problematisch ist das nur im Zusammenhang mit dem VSync (im PC).

Dann muss das Problem ja genau so auftreten wenn der Ton Analog über den PC ausgegeben wird oder?

[nuts]

Ja tut es auch. Das ist eben das alte Reclock Thema, wobei es da eher um Ruckler und nicht um den A/V Drift ging.

Zumindest wenn man die Meinung vertritt, dass eine Directshow Komponente für den Drift verantwortlich ist und davon bin ich fest überzeugt.

Edited July 24, 2014 by nuts

[CiNcH]

 

Der Unterschied durch einen anderen Taktgebern ist konstant und nicht sehr hoch.

 

Ja, er ist konstant. In jedem Zyklus wird die Lücke um diese Konstante größer. Die Größe der Konstante hängt von den Genauigkeiten der involvierten Uhren ab.

[Tjod]

dass eine Directshow Komponente für den Drift verantwortlich ist und davon bin ich fest überzeugt.

Wenn das nur ein Windows Problem wäre bräuchte man solche Sachen wie Wordclock nicht.

 

Und warum tritt das nicht bei Analoger Ausgabe auf? Wenn es an einem Directshow Komponente liegen sollte dürfte es keinerlei Unterschied machen oder?

[nuts]

Ich kann dir da gedanklich schon folgen, aber dieses Problem wäre dann bei jedem Gerät mit bitstream Ausgabe vorhanden.

Wie genau HDMI die dekodierten Daten letztendlich in Einklang bringt weiß ich leider nicht.

 

Für mich ist das nicht der entscheidende Punkt.

Woran es genau liegt kann ich auch nicht sagen.

Könnte Decoder, Sourcefilter oder Renderer sein (wobei im Videorenderer immer der Bezug zur Audiouhr gesucht wird oder?)

[nuts]

Habe nun mal noch etwas gegoogelt.

HDMI enthält einen sogenannten tmds Clock Channel.

Könnte doch sein, dass der Offset so übermittelt wird? Ich glaube nicht so ganz daran, dass das schon per Design gar nicht funktionieren kann!

Edited July 24, 2014 by nuts

[CiNcH]

Ich habe mich gerade per S/P-DIF verbunden und den AC3 Encoder von ReClock probiert. Damit haben im PC alle die gleiche Uhr (außer die Streamquelle bei Live-TV). Da Audio vorher dekodiert wird, kann man auch bereits im PC im Audio Dekoder (AC3Filter, ffdshow, LAV) konstante Versätze ausgleichen. Damit hat man die gleiche Lösung wie mit dem MediaPortal Audio Renderer.

[nuts]

Und du synchronisierst die Audioabspielgeschwindigkeit auf den VSync nehme ich mal an (Reclock ist ja auch ein Einstellungsmonster).

[CiNcH]

ReClock stellt die Referenzuhr und ist somit synchron mit dem VSync, richtig.