Jump to content

Tonaussetzer


Eichhorn

Recommended Posts

Ich habe seit geraumer Zeit Tonaussetzer beim Anschluß meines AV Receivers per SPDIF optisch. Ich habe hier im Forum auch schon ältere Beiträge ohne Ergebnis gelesen. Ich habe bemerkt, das diese Aussetzer nur auftreten, wenn ich das empfangene Fernsehbild "direkt" ausgebe. Bei Aufnahmen, welche ich mit dem DVBViewer gemacht habe treten keine Tonaussetzer auf. Ebenso ist der Ton einwandfrei, wenn ich im Film kurz auf "Stop" drücke und sofort wieder "Play", so das es per Timeshift wiedergegeben wird. Als Audiodecoder nutze ich den AC3 Filter und als Videodecoder den Cyberlinkdecoder. Was ich allerdings bemerkt habe, unter Ansicht--->Filter--->Default DirectSound Device gibt es eine Karte erweitert. Dort gibt es eine "Völleanzeige" eines Puffers, welche während der Wiedergabe stark zwischen 20 und 40% schwankt. Wenn ich jetzt auf "Pause" drücke steigt der Puffer auf 100% an, jetz drücke ich wieder auf "Play" (also Timeshift), da hat der Puffer einen konstanten Wert von 90%. Jetzt gibt es unter Ansicht--->Filter--->DVB Source. Wenn ich dort den Latency Wert von 350 auf 800 erhöhe, dann schwankt der Puffer wenigstens zwischen 60 und 80%. Geht aber manchmal kurzzeitig auf 30% runter. Kann mir bitte jemand erklären ob diese Tonaussetzer damit zusammen hängen können? Was bewirkt das verändern des Latency Wertes noch? Ich habe da keinen Plan, habe einfach rum probiert. Gibt es für mein Problem eine Lösung? Ich hatte jetzt nicht genügend Zeit zum Testen, ob die Tonaussetzer durch Erhöhen des Latency Wertes weg sind. Ich nutze den EVR als Renderer.

Gruß Eichhorn

Link to comment
Was bewirkt das verändern des Latency Wertes noch?

Eine Erhöhung verschiebt die Zeitstempel, die den Zeitpunkt der Wiedergabe bestimmen (PTS, Presentation Time Stamp), in die Zukunft. D..h. bei Live-Betrieb verlängert sich die Zeitspanne zwischen Ankunft und Wiedergabe der Daten im DVBViewer. Das Ergebnis ist eine erhöhte Pufferung (und damit erhöhter Speicherbedarf) im DVBViewer Filter und/oder nachfolgenden Wiedergabe-Komponenten, denn irgendwo müssen die Daten ja so lange bleiben. Außerdem verlängern sich die Sender-Umschaltzeiten. Auswirkungen hat man i.a. nur bei Video, da die Zeitstempel der Synchronisation zwischen Video und Audio dienen.

 

Eventuell muss man gleichzeitig den Wert für TV/Radio - Max. Queued Audio erhöhen, um zu verhindern, dass die Überpufferungskontrolle des DVBViewer Filters zuschlägt und einen Fehler an den DVBViewer meldet, der dann die Wiedergabe kurz anhält und gleich wieder startet, um die Sache in Ordnung zu bringen.

 

Eine unbekannte Größe in dem Spiel ist das Pufferungsverhalten der DVB-Gerätetreiber. Die Daten werden von ihnen nicht kontinuierlich, sondern stoßweise an den DVBViewer ausgeliefert - im allgemeinen immer, wenn ein Treiber-Puffer gefüllt ist. Wenn die Zeitspanne zwischen zwei Lieferungen zu lang wird, kann es zu den von dir beschriebenen Aussetzern kommen, weil die DirectShow-Komponenten nicht mehr in der Lage sind, die Lücke aus eigenen Puffern zu überbrücken.

 

Bei Dateiwiedergabe ist das kein Problem, da hierbei nach Bedarf gelesen wird. Bei Live-Betrieb kann der DVBViewer die "Daten-Produktionsrate" jedoch nicht steuen.

Link to comment

Kann man also durch Erhöhung des Latency Wertes den Tonaussetzern entgegen wirken? Bis zu welchen Werten kann man das "treiben"? Zur Zeit habe ich einen Wert von 550 eingestellt. Bei TV/Radio - Max. Queued Audio ist ein Wert von 500 eingestellt. Ob es nun Zufall ist, aber ich hatte den ganzen Abend über nur einen einzgen kurzen Tonaussetzer. Ist das der richtige Weg den Tonaussetzer zu bekämpfen oder gibt es noch eine andere Möglichkeit?

Link to comment
Ist das der richtige Weg den Tonaussetzer zu bekämpfen

Ja, zumindest für Video.

 

oder gibt es noch eine andere Möglichkeit?

Bislang nicht. Ich befasse mich gerade mit dem Problem, da ich insbesondere bei Radiowiedergabe auch ab und wann kleine Aussetzer habe - nicht so stark, dass es wirklich stört, aber ohne wäre schöner.

 

Die Völle-Anzeige des Audio Renderers ist dabei relativ niedrig (unter 20%) - offenbar wird nicht genug gepuffert, um alle Pausen im stoßweise ankommenden Datenstrom überbrücken zu können, die sowohl aus dem Pufferungsverhalten der DVB-Gerätetreiber als auch aus der Art, wie der Audiostream in den Gesamt-Datenstrom des Transponders hineingemuxt ist, resultieren. Irgendwie müsste der DVBViewer Filter noch mehr Daten vorhalten, und dafür suche ich zur Zeit einen geeigneten Ansatzpunkt.

Link to comment

Hatte ich doch eben mit nur einem Tonaussetzer über den Abend geprahlt, hatte ich eben mit diesen Werten kurz hinter einander 3 Stück. Ich werde jetzt mal mit einem Latency Wert von 800 testen. Hoffentlich bekomme ich mit diesem Wert nicht den von Dir beschriebenen Überpufferungskontrolle. Radio höre ich nicht über den DVBViewer, hatte aber eben mal auf einen Radiosender umgeschalten. Da schwankt mit diesen Werten die Puffervölle auch stark zwischen 40 und 50%.

Link to comment
Hoffentlich bekomme ich mit diesem Wert nicht den von Dir beschriebenen Überpufferungskontrolle.

Die kannst du auch ganz abschalten, indem du Max Queued Audio für TV/Radio auf 0 setzt. Würde ich bei deinen Experimenten erst mal machen.

Link to comment

Bei einem Latencywert von 800 schwankt der Pufferwert zwischen 65 und ca. 78% Den Max Queued Audio für TV/Radio Wert habe ich auf 600 erhöht. Hatte es jetzt 5 Minuten laufen und keinen Fehler bemerkt. Wie zeigt sich eigentlich der "Pufferüberlauf"? Durch ruckeln oder wird die Wiedergabe dann direkt kurz angehalten, was man deutlich merkt? WIe kann man diesen Zustand vielleicht mal zur Ansicht provozieren, damit man es deutlich sieht?

 

Jetzt gehe ich aber erst einmal ins Bett! :lol:

Link to comment
Wie zeigt sich eigentlich der "Pufferüberlauf"?

Bei einem wirklichen Pufferüberlauf gehen Daten verloren, und dann gibt's erst recht Aussetzer der unschönen Art, also eventuell mit Bild- und Tonartefakten.

 

Die Pufferungskontrolle im DVBViewer Filter wartet aber nicht so lange. Der Max Queued Audio-Wert besagt, wieviel Millisekunden Audio höchstens in den Puffern auflaufen dürfen. Sie ist gedacht für den Fall, dass z.B. durch andere Aktivitäten im PC die Wiedergabe gegenüber den empfangenen Daten in Zeitverzug kommt und damit zunehmend zu einer Art "Timeshift aus dem RAM" wird. Ab einem bestimmten einstellbaren Ausmaß wird dann die Wiedergabe abgebrochen und neu gestartet. Wenn du für Max Queued Audio 600 einstellst, besagt das, dass dieser Mechanismus zuschlägt, sobald mehr als 600 Millisekunden Audio in den Puffern auf die Abholung durch den Decoder warten, oder mit anderen Worten, dass die Wiedergabe mehr als 600 Millisekunden hinter dem Live-Datenstrom hinterher hinkt.

Link to comment

Letzte Nacht habe ich den DVBViewer Filter dazu bewegt, mehr Daten vor dem Wiedergabebeginn zu puffern. Sah bei Radio-Wiedergabe (abgesehen von längeren Sender-Umschaltzeiten) zunächst gut aus: Puffer-Füllstand im Audiorenderer 70%, keine Aussetzer. Doch das blieb nicht so. Allmählich sank der Füllstand auf 60%... 50%... 40%... wenn ich lange genug warte, sind die Mikro-Aussetzer wieder da.

 

Ursache dürfte sein, dass meine Soundkarte (bzw. ihr Quarz) aufgrund unvermeidlicher Toleranzen schneller als der Sender ist. Oder anders gesagt: Was mit einer Samplerate von 48 khz gesendet wird, spielt mein PC mit einer geringfügig höheren Samplerate ab (d.h. die Tonhöhe ist geringfügig zu hoch). Auch der umgekehrte Fall ist möglich: Dass eine Soundkarte eine Spur langsamer als der Live-Stream ist. Dann gibt es zwar keine Aussetzer, aber über einen längeren Zeitraum stauen sich Daten.

 

Wenn ich daraus ein hartes Fazit ziehe, lautet es: Ein PC ist für Dateiwiedergabe, aber nicht für die Wiedergabe von TV/Radiostreams geeignet, da es keine Möglichkeit gibt, die Geschwindigkeit der Wiedergabe exakt mit der des Senders zu synchronisieren. Zwar funktioniert es in der Praxis schon, aber nicht hundertprozentig glatt, zumindest nicht über einen beliebig langen Zeitraum.

Link to comment

Hallo,

 

auch bei meinen HTCP (Vista32 & DVBViewer 3.9.4), der über SPDIF an meinen AV-Receiver angeschlossen ist, treten gelgentlichTonaussetzer aus. Allerdings bin ich mir nicht sicher ob das Problem nicht von einem ev. minderwertigen optischen Toslink Kabel herrührt (3m - hat glaub ich nur €10 gekostet). Auf jeden Fall sieht man am AV-Receiver, dass das DolbyDigital Signal dann kurzfristig komplett weg ist. Ist das bei euch auch der Fall?

 

Im DirectX Audio Render hab ich allerdings "Realtek Digital Output" anstatt "Default DirectSound Device" eingestellt, was dazu führt das die Anzeige Völle immer auf - % steht. Stelle ich auch Default DirectSound um, schwankt der Wert zwischen 20-40%. Habt ihr diese Einstellungen auch mal probiert?

Link to comment

Also ob das Signal dann mal kurz weg ist weiß ich nicht, da ich nicht ständig auf das Kabel starre! :lol: Bei mir sind die Tonaussetzer NUR! beim LiveTV des DVBViewer. Wie gesagt, wenn ich kurz Stop drücke und dann sofort wieder auf Play, so das die Daten von der HDD kommen ist es weg. Wenn ich z.B. Musik per WinAmp höre (natürlich auch über SPDIF) gibt es auch keine Fehler. In dem Fall kommt das Signal ja auch von HDD. Ich habe aber bisher keine Regelmäßigkeit in Beziehung der Tonaussetzer rein bekommen. Manche Abende habe ich vielleicht den ganzen Abend über einen einzigen Aussetzer und manchmal ist es richtig nervig. (da bekommt es sogar die Frau mit :lol: ) Es ist dabei völlig egal in welchem Tonformat der Film ist (Stereo, Dolby 2.0 oder 5.1) Ich habe allerdings noch nicht länger mit meinen weiter oben beschriebenen Einstellungen fern gesehen. Man kann ja nun nicht ständig vor der Glotze hängen!

 

Gruß Eichhorn

Link to comment

@ Griga,

 

auf welchen Radiosendern tritt das bei dir auf? Sind die auf Astra oder HotBird? Wie lange musst du warten, bis es zu diesem Phänomen kommt? Ich würde das auch gerne mal probieren...

Link to comment
auf welchen Radiosendern tritt das bei dir auf?

Bei allen. Der Ausgang des Experiments hängt natürlich davon ab, wie die Soundkarte bzw. ihr Taktgeber geeicht ist. Außerdem bräuchtest du dazu den experimentellen DVBSource, der erst mal vier Audiopuffer auflaufen lässt, bevor er mit der Auslieferung beginnt.

 

Wie lange musst du warten, bis es zu diesem Phänomen kommt?

Nach ungefähr zwanzig Minuten ist die (allerdings ständig schwankende) Puffer-Füllstandsanzeige des Audiorenderers um ca. 10% gesunken. Beginnt z.B. bei 60%. Bei Werten um die 10% kommt es zu Millisekunden-Pausen im Ton, was die Eigenschaftsseite des Audiorenderers auch anzeigt.

Link to comment
Der Ausgang des Experiments hängt natürlich davon ab, wie die Soundkarte bzw. ihr Taktgeber geeicht ist.

Genau das will ich testen. Ich habe nun OE3 laufen. Puffer ist momentan bei durchschnittlich 20%. Ich werde dann nach einer Stunde mal reinhören.

 

Zeigt der Audio-Renderer denn bei den Aussetzern auch Diskontinuitäten an?

Link to comment

hmmm... mein SPDIF ist über Koax am AVR angeschlossen, wobei ich auffällig nur bei

AC3 codierten Sendern teilweise recht heftige Aussetzer habe.

 

Dieses Phänomen ist aber bereits bei der vorher vorher vorhandenen STB von Hyundai

aufgetreten - 'normaler' Stereo-Empfang ist in der Regel einwandfrei, AC3 'hackt'...

mal mehr, mal weniger

Einen zeitlichen Zusammenhang konnte ich bisher nicht feststellen bzw. reproduzieren

Link to comment
Zeigt der Audio-Renderer denn bei den Aussetzern auch Diskontinuitäten an?

Eher Pausen (w00t) siehe unten. Die Anzahl steigt allmählich an, ebenso wie die Zeit ohne Ton - die Angabe ist kumulativ und zeigt, dass pro Pause der Ton ca. 10 ms aussetzt.

 

Was dort als eine Diskontinuität erscheint, stammt wahrscheinlich von einem entsprechend markierten Sample. Der DVBSource macht das vorsichthalber bei jedem ersten Sample nach einem Stop -> Run (und natürlich auch bei Samples, nachdem einer Diskontinuität im Transportstream aufgetreten ist).

 

Wenn es allein an der Pufferung durch den DVB-Gerätetreiber, den daraus resultierenden stoßweisen Datenlieferungen und entsprechenden zeitlichen Lücken läge, müsste es sich nach einer bestimmten Zeit durch die vom Renderer eingelegten Pausen von selbst stabilisieren. Tut es bei mir aber nicht, da die Soundkarte permanent die Daten eine Spur zu schnell abarbeitet. Da die Soundkarte die Reference Clock für den gesamten Filtergraphen liefert, müsste es eigentlich auch Auswirkungen auf Video haben. Allerdings läuft bei mir MPEG2 recht flüssig.

Zwischenablage01.png

Link to comment

Ja, das konnte ich bei mir auch nachvollziehen. Irgendwann ist der Völlegrad bei 10% und dann beginnt er zu pausieren (sowohl bei Radio als auch TV). Dass das auch Auswirkungen auf Video haben müsste, war auch mein Gedanke, im Video-Renderer war aber kein Jitter oder Sync-Offset festgehalten.

Edited by CiNcH
Link to comment

Ich kann die Erkenntnisse meiner Vorredner leider nur bestätigen. Gestern fing es hörbar ca. nach einer Stunde an mit den Aussetzern. Die Völle schwankte bei mir zu diesem Zeitpunkt stark um 20% und darunter. Allerdings hatte ich zu diesem Zeitpunkt Pausen 14 und kein Ton lag erst bei 56ms.

Link to comment

Zumindest bei PCM sind diese Aussetzer für mich nicht hörbar.. AC3 Passthrough könnte wieder eine ganz andere Geschichte sein..

Edited by CiNcH
Link to comment

Ich dachte, du gibst komprimiertes AC3 an die externe Audioanlage via S/P-DIF (also Passthrough-Verfahren im AC3Filter)!?

Edited by CiNcH
Link to comment

Das sind ja mal tolle Einstellungen. So wie ich das verstehe wird hier AC3 dekodiert (PCM, mit 5.1 Upmix?) und anschließend neu kodiert (5.1 AC3), was dann auf den S/P-DIF ausgegeben wird (5.1 Kanäle kann man nicht als PCM auf den S/P-DIF ausgeben, sondern nur als komprimiertes AC3 oder DTS). Bei dieser Kette wundert es mich fast nicht mehr, dass es zu Schluckauf kommt ;) .

Denke dass das von Griga angesprochene Problem ganz ein anderes ist, auch wenn ich sagen muss, dass mich das sehr interessiert, sprich Zeitsynchronisation in einer Push-Umgebung.

Edited by CiNcH
Link to comment

Warum die pcr die souncard clock nicht synchronisieren kann, ist mir zwar immer noch unverständlich, aber ich habe jetzt auch mal einen test laufen.

 

BBC R1 (28E, 11953H) mit 48khz/192kbps läuft seit mehr als 2h 30min ohne aussetzer. Intervideo audiodekoder, dvbsource 3.2 mit standardeinstellungen. In den 2,5h ist die puffervölle des direct sound device von rund 40% um ca. 10% gesunken. Ein aussetzter ist also irgendwann zu erwarten. Wenn man aber nicht stundenlang den selben sender hört, fällt es wahrscheinlich nicht auf ;)

 

Wenn pcr und wiedergabe asynchron sind, kann es theoretisch aber auch vom sendeseitigen muxer abhängen...

Link to comment

..nach 4,5h zeigen sich pausen bei mir. Hörbar sind sie aber nicht (kann auch am content liegen ;) ). Im gegensatz zu Grigas ansicht werden bei mir die pausen mit jeweils 2ms inkrementiert und die pufferdauer ist 24ms. Das entspricht einem frame und macht imho mehr sinn als die 21ms in dem anderen screen shot.

Link to comment

Interessant, was in WatchTVPro vom Audio-Renderer so angezeigt wird (siehe Slavinginfo).

 

wtvp_audiorenderer.jpg

 

Mal sehen ob da der Puffer auch in den Keller geht.

Edited by CiNcH
Link to comment

Aha, die Frequenz in der Slavinginfo variiert (47850 Hz <-> 47925 Hz <-> 48150), sehr interessant. Puffer wird nicht kleiner. Die Audioausgabe wird da tatsächlich adaptiv angepasst.

 

click

 

Der MS MPEG-2 Demultiplexer kann es wohl.

 

Funktioniert ja ähnlich wie ReClock, wo ja auch die Audiofrequenz adaptiv angepasst wird. Was dieses Resampling qualitative für Auswirkungen hat, kann ich nicht sagen. Bin kein Audiophiler...

 

Wie das wohl im Fall von SPDIF Passthrough synchronisiert wird!? Muss ich mir auch mal anschauen..

Edited by CiNcH
Link to comment

ja diese Aussetzer haben mich damals nach dem Kauf der SS2 zur Weisglut gebracht. Viel später stellte sich heraus, auf der Soundkarte war ein völlig falscher Quarz aufgelötet, oben stand 14,318.... Mhz (oder so ähnlich, wie die eben alle sind) nach dem Auslöten und Umdrehen die Überraschung: steht da 14,7... und irgendwas Mhz. Das war genau die Differenz was die Musik immer zu schnell war. ;)

 

@CiNcH: so ein ähnliches Bild habe ich eben auch produziert.Ich habe mal noch eine Soundkarte zusätzlich eingebaut, die produziert auch nach einer gewissen Zeit aussetzer, ist geringfügig zu schnell.

Nun habe ich eine Aufnahme mit mehreren Audiospuren genommen und in Graphstudio rendern lassen. die Audiorenderer habe ich dann durch die beiden Soundkarten ersetzt. Soundmax (ist der Onboardsound,da stimmt das Tempo) die spielt den Taktgeber (gelbe Uhr). Die C-Media ist der Slave,

Da schaltet die Frequenz, wie Du auch beobachtet hast, ab und zu in 75Hz Schritten hin und her.

Aussetzer habe ich bei der C-Media im Kopfhörer nicht gehört.

Die Uhr bekommt denke ich immer der Renderer, welcher zuerst verbunden wurde, kann man mit "use Clock" gelb machen.

Bei Graphedit geht das mit der rechten Maustaste umzuschalten glaube ich.

 

Edit: ja bei Graphedit kann die Clock im Stopzustand umschalten, eben mal probiert

Edited by gwr
Link to comment
Warum die pcr die souncard clock nicht synchronisieren kann, ist mir zwar immer noch unverständlich,

Weil sich die Ankunftszeit der TS-Pakete mit PCR nicht mit ausreichender Präzision feststellen lässt. Die haben ja, bevor sie den DVBViewer erreichen, schon unbekannte und vor allem uneinheitliche Verzögerungen durch Pufferung durchlaufen. Das ist so, als hättest du einen Zettel, auf dem irgendwann Uhrzeiten notiert worden sind, und du willst mit dieser Information eine Uhr justieren...

 

Vor längerer Zeit diente der DVBViewer Filter (Version 1.0) nur dazu, den Transportstream in den Wiedergabegraphen einzuspeisen. Ihm nachgeschaltet war der MS Demultiplexer, der eine auf der PCR basierende Reference Clock erzeugt. Wir haben natürlich probiert, sie zu benutzen. Da sie einen enormen Jitter aufwies, war das Ergebnis bei Video ziemlich ruckelig. ;) Hinzu kam, dass Sender ohne PCR (kommt bei Radio mal vor, z.B. AAC aus Österreich via Astra 23°) sich überhaupt nicht wiedergeben ließen, weil der MS Demultiplexer ohne PCR schlicht den Betrieb einstellte.

 

Seitdem benutzt der DVBViewer den Audiorenderer als Reference Clock. Eine bessere Lösung wäre eine von den DVB-Karten bereitgestellte PCR-basierte Hardware-Uhr. Doch die gibt's nirgendwo, soweit ich weiß.

Link to comment

..es soll ja nur die mittlere abweichung langsam korrigiert werden. Mit ensprechenden schaltungen (pll-filter) sollte das gehen. Anscheinend machen andere (screen shot von CiNcH) das ja auch ;)

Link to comment
wo ja auch die Audiofrequenz adaptiv angepasst wird. Was dieses Resampling qualitative für Auswirkungen hat, kann ich nicht sagen. Bin kein Audiophiler...

Du ersetzt Pausen durch Tonhöheschwankungen ;)

 

Interessant ist auch das hier:

 

http://groups.google.com/group/microsoft.p...cf06452959ad29d

 

Kurz gesagt geht daraus hervor, dass der Sourcefilter den Audiorenderer in verschiedene Modi schalten kann, indem er das IAMPushSource-Interface implementiert (womit er sich als PushSource-Filter zu erkennen gibt). Dabei kommt es auf darauf an, was er dem Audiorenderer erzählt, wenn dieser IAMPushSource.GetPushSourceFlags abfragt. Bis zum DVBViewer Filter 3.0.2 war das AM_PUSHSOURCECAPS_NOT_LIVE. Scheint für TV/Radio widersinnig, aber wenn ich es probeweise geändert habe, kamen früher oder später Rückmeldungen, es würde irgendwo böse ruckeln.

 

Im DVBViewer Filter ab 3.2.0 habe ich deshalb das Interface ganz rausgeworfen. Gerade wieder implementiert, und dabei gemäß dem obigen Link den Wert 0 für pFlags zurückgegeben, also ohne ein Flag zu setzen (ich weiß nicht mehr, ob ich das schon früher probiert habe...). Damit arbeitet der Audiorenderer adaptiv (siehe Screenshot unten). Nach dem Einschalten eines Senders steigt die Anzahl der Pausen für kurze Zeit stark an, und dann stabilisiert sich die Sache. Für Dateiwiedergabe via DVBSource scheint dieser Modus eher ungünstig zu sein, aber in dem Fall kann man AM_PUSHSOURCECAPS_NOT_LIVE zurückgeben, worauf der Audiorenderer konstant bei 48 KHz bleibt.

Zwischenablage01.png

Link to comment

Ich nehme an, dass bei 'Graph Clock' ein anderer Filter die Referenzzeit stellt (e.g. MS MPEG-2 Demultiplexer wie im Fall von WatchTVPro). Das ist dann wohl der folgende Ansatz:

As Michel has suggested, there are a number of solutions to this. My preferred solution is to slave the client graph to the incoming data rate instead of the audio DAC. To do this, you need to implement IReferenceClock at your source filter and ensure that it is selected as the graph clock. Monitor the timestamps as they arrive at your source, and generate the clock from this. The audio renderer will then adjust its output rate to match your clock and (although this means slight changes to the pitch) it will sound pretty good and you will not have underflow or overflow.

Das entspricht dann wohl AM_PUSHSOURCECAPS_PRIVATE_CLOCK.

 

 

Aber was macht 'Live Fullness'? Wenn GetPushSourceFlags 0 zurück gibt passiert laut hier wohl folgendes:

If the audio renderer is the graph clock, it tries to match the incoming data rate.

 

 

Auch von diesem Link:

The demux guarantees that the time stamps increase monotonically. This means, for example, that if a transport stream includes a segment such as a commercial that was created with a different clock than the main program, the demux will adjust the presentation time stamps to hide the time discontinuity from downstream filters.

Das wäre doch auch für unterbruchsfreie Fileübergänge interessant...

Link to comment

Graph Clock: Die Graph Clock liefert ein anderer Filter, und der Audiorenderer passt die Frequenz an die Zeitstempel der ankommenden Samples an.

 

Live Fullness: Der Audiorenderer ist Graph Clock und passt die Frequenz an die eintreffende Datenrate an. D.h. wenn sich sein Puffer zunehmend füllt, erhöht er die Frequenz, um die Daten schneller zu verarbeiten, und umgekehrt.

 

So verstehe ich jedenfalls den Abschnitt über Rate Matching:

 

http://msdn.microsoft.com/en-us/library/ms787249(VS.85).aspx

 

Was hier nur schlecht funktioniert, ist AM_PUSHSOURCECAPS_PRIVATE_CLOCK (Modus-Anzeige: "Live Timestamps"), obwohl das für eine Live-DVB-Quelle eigentlich passend erscheint. Dabei geht der Renderer hier konstant auf Maximalfrequenz (48,6 KHz, also viel zu hoch) und produziert so natürlich Pausen ohne Ende.

 

Das Kapitel ist eines der schwierigsten im DirectShow-Bereich, und vollständig verstehe ich es noch nicht. Die besten Ergebnisse erhalte ich mit pFlags = 0, d.h. es gibt nach einiger Zeit keine Pausen mehr, aber die dabei auftretenden Frequenzschwankungen sind relativ zahlreich und hoch. Sie könnten damit zusammenhängen, dass der DVBSource möglichst den Inhalt eines PES-Pakets mitsamt dazugehörigem PTS gesammelt abliefert - das sind zum Beispiel bei MPEG Audio vom Ersten immer 6 Frames = 144 ms auf einmal. Führt zu effizienter Puffernutzung, aber stellt eventuell den Rate Matching-Mechanismus des Renderers vor Probleme, weil die Daten in relativ großen zeitlichen Abständen kommen. Vielleicht funktioniert es glatter, wenn die Lieferungen frameweise erfolgen, also sofort sobald ein Frame vollständig vorliegt (d.h. beim Ersten würden aus einem Sample dann über die Zeit verteilt 6). Das möchte ich probieren, muss dazu aber erst allerhand umbauen.

 

Eine unbekannte Größe in dem Spiel ist noch der Audio Decoder, bzw. was der mit den Samples und Zeitstempeln macht - mit verschiedenen Decodern gibt es hier teilweise unterschiedliche Ergebnisse.

Link to comment
Graph Clock: Die Graph Clock liefert ein anderer Filter, und der Audiorenderer passt die Frequenz an die Zeitstempel der ankommenden Samples an.

 

Live Fullness: Der Audiorenderer ist Graph Clock und passt die Frequenz an die eintreffende Datenrate an. D.h. wenn sich sein Puffer zunehmend füllt, erhöht er die Frequenz, um die Daten schneller zu verarbeiten, und umgekehrt.

Genau so habe ich das auch verstanden, siehe voriges Posting von mir. Könntest du mal eine Alpha mit Flag 0 zur Verfügung stellen? Ich würde das gerne mal testen.

Link to comment
Das entspricht dann wohl AM_PUSHSOURCECAPS_PRIVATE_CLOCK.

Eher pFlags = 0 mit einer Reference Clock, die nicht auf dem DAC der Soundkarte basiert.

 

If GetPushSourceFlags returns no flags (zero), the audio renderer's behavior depends on the graph clock and whether the samples have time stamps:

If the audio renderer is not the graph clock, and the samples have time stamps, the audio renderer matches rates against the time stamps.

 

AM_PUSHSOURCECAPS_PRIVATE_CLOCK

The filter time stamps the samples using a private clock. The clock is not available to the rest of the graph through IReferenceClock.

Deshalb erschien mir AM_PUSHSOURCECAPS_PRIVATE_CLOCK für unseren Fall passend, bringt aber hier wie gesagt keine guten Ergebnisse.

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...