Jump to content

Tonaussetzer


Eichhorn

Recommended Posts

Naja ok, Ton kann man immerhin mit Resampling synchronisieren. Aber wie sieht das bei Video aus? Ich nehme mal an, dass hier die Genauigkeit nicht so groß sein muss, da man hier lediglich 25 Bilder pro Sekunde ausgeben muss und nicht 48000 Samples!?

Link to post

Mpeg (ISO13818-1) kennt eine system clock. Damit sind alle streams eines programms beim sender synchronisert. Nach dem transport wird diese clock aus der PCR regeneriert. Wenn der empfänger diese clock verwendet, kann es keine verluste geben.

Link to post
Ton kann man immerhin mit Resampling synchronisieren.

Stimmt so nicht. Resampling ist das Umsetzen von Audio auf eine andere Samplerate (z.B. von 48000 Hz auf 44100 Hz für eine Audio-CD), wobei sich weder die Dauer noch die Tonhöhe verändern. Aus einer Sekunde Audio mit 48000 Samples wird eine Sekunde mit 44100 Samples gemacht (also praktisch eine Verringerung der Auflösung) - wäre ja auch unerwünscht, wenn eine DVB-Radioaufnahme als Audio CD langsamer abgespielt würde, was der Fall wäre, wenn man einfach im WAV-Header die Samplerate von 48000 auf 44100 patcht. Resampling ist eine Wissenschaft für sich und ziemlich aufwändig, wenn hörbare Artefakte vermieden werden sollen.

 

Deshalb wird in unserem Fall kein Resampling stattfinden, da es ja gerade darauf ankommt, die Zeitdauer der Wiedergabe einer bestimmten Audio-Datenmenge zu verändern. Es dürfte sich beim Rate Matching gemäß dieser Aussage

 

The audio renderer will then adjust its output rate to match your clock and (although this means slight changes to the pitch)

um eine reine Frequenzanpassung handeln.

 

Aber wie sieht das bei Video aus?

Der Videorenderer speichert die Frames zunächst mitsamt Zeitstempeln, was insbesondere notwendig ist, weil sie nicht zwangsläufig in der gesendeten Reihenfolge wiedergegeben werden - Umstellungen für eine effektivere Kompression sind erlaubt, und wenn man sich die PTS eines DVB-Videostreams anschaut, sieht man, dass die Zeitstempel munter vor und zurück springen.

 

Weiterhin beauftragt der Videorenderer die Instanz, die IRefenceClock bereitstellt, mit AdviseTime, einen Event auszulösen, wenn der Zeitpunkt der Darstellung gekommen ist, damit der Videorenderer nicht laufend die Uhr abfragen muss. Deshalb ist die Implementation von IReferenceClock hinsichtlich einer flüssigen Bilddarstellung und einer synchronen Wiedergabe kritisch.

 

When a renderer filter receives a sample, it schedules rendering based on the time stamp. If the sample arrives late, or has no time stamp, the filter renders the sample immediately. Otherwise, the filter waits until the sample's start time before it renders the sample. (It waits for the start time by calling the IReferenceClock::AdviseTime method.)

 

@Derrick: Du gehst vom Idealfall einer homogenen und für einen einzigen Zweck bestimmten Hard- und Software-Umgebung aus, wie sie in einem Receiver gegeben ist. PC-Architektur ist jedoch anders. Deine Anmerkungen sind deshalb irrelevant.

Link to post

..es scheint am verständnis der grundlagen zu mangeln. Ob in einer STB die lokale clock synchronsiert wird oder in einem PC - und in dieser umgebung auch nur die einer peripheren einheit - bleibt sich im prinzip gleich. Umsetzung ist natürlich eine andere sache.

Link to post

Leider fehlt mir für das "Eingemachte" auch etwas der Durchblick. Ist das ganze denn nun Soundkartenabhängig? Wenn ja, ich nutze z. Z. eine extra Soundkarte, weil bei meinem Board das Slotblech mit den Anschlüssen für optischen und Koaxialausgang optional waren und fehlten. Wenn es Soundkartenabhängig ist, würde ich mir dieses Slotblech mal besorgen und die OnBoard Soundkarte probieren. Wenn es natürlich nicht Soundkartenabhängig ist, dann hat es keinen Zweck.

Link to post

..will mal so sagen, mit der derzeitigen directshow-konfiguration ist es immer kartenabhängig. Allerdings wird es u.u. erst nach stunden auftreten. Ob und wie es anders kann, weiss ich nicht..

Link to post
Deshalb ist die Implementation von IReferenceClock hinsichtlich einer flüssigen Bilddarstellung und einer synchronen Wiedergabe kritisch.

Also wenn die Videoausgabe mit der PCR synchronisiert ist, macht es Sinn, diese zu verwenden. Im MS MPEG-2 Demultiplexer wird das auch gemacht und die Videoausgabe (PAL) ist butterweich auf einem 50 Hz Anzeigegerät (getestet auf Bloomberg TV Germany). Audio ist synchron zum Video und wird adaptiv gemäß pFlags 0 angepasst. Morgen werde ich den Langzeittest machen und auch nochmal meine "Analyse Ruckelproblem" miteinfließen lassen.

DVBSource berechnet momentan ja einmalig den Offset zwischen PCR und DS/Audio-Clock und wendet diesen dann fortlaufend an. Das Problem dabei ist halt, dass Uhren driften. Auch wenn man einen Kanal wohl nie so lange eingestellt hat, dass das auffällt!?

Link to post
Also wenn die Videoausgabe mit der PCR synchronisiert ist,

Was verstehst du unter "Videoausgabe mit der PCR synchronisieren"? Ein Zusammenhang zwischen PCR und Bildwiederholrate der Grafikkarte / des Anzeigegeräts ist in einem PC nicht gegeben und lässt sich auch nicht herstellen.

Link to post

Bei einem Sender, der einen Sinusdauerton ausstrahlt (Hotbird 10775 H, Bars and Test Tone +4.0 dBu), sind sowohl die Pausen als auch die Tonhöheschwankungen bei Frequenzanpassung hörbar. Fragt sich, was vorzuziehen ist...

 

Zur PCR:

 

http://www.tek.com/Measurement/App_Notes/2...25W_14706_0.pdf

 

PCRs are snapshots of a counter, driven by this program clock, that are inserted into packets within the Transport Stream (TS) at more or less

regular intervals (ISO/IEC13818-1 specifies an interval of 100 ms, while DVB recommends 40 ms).

...woraus deutlich wird, dass die PCR keine Uhr ist und auch nicht als solche verwendet werden kann. Es handelt sich um ein Signal, das dazu gedacht ist, eine Empfänger vorhandene Uhr zu synchronisieren, idealerweise einen 27 MHz-Oszillator per Hardware, was im PC jedoch nicht möglich ist.

 

Aufgabe für Derrick: Ein Transponder mit gegegbener Symbolrate, ein DVB-Gerät, das den gesamten Transponder-Datenstrom empfängt und in einem n Bytes großen Puffer speichert (n kann als Vielfaches von 188 angenommen werden). Er wird an die Anwendung ausgeliefert, sobald er voll ist. Ein TS-Paket mit PCR, das am Anfang des Puffers abgelegt wird, erleidet eine enstprechende Verzögerung. Ein am Ende abgelegtes nicht. Durch die PC-Architektur (Multitasking) bedingte unkalkulierbare Verzögerungen lassen wir mal außer Acht. Wie lässt sich der PCR-Jitter in ms durch die Pufferung in Abhängigkeit von der Symbolrate und der Puffergröße berechnen?

Link to post
...woraus deutlich wird, dass die PCR keine Uhr ist

..hat niemand behauptet und ich schon gar nicht.

 

Ein TS-Paket mit PCR, das am Anfang des Puffers abgelegt wird, erleidet eine enstprechende Verzögerung. Ein am Ende abgelegtes nicht.

Die daten werden doch in derselben reihenfolge ausgelesen wie sie reingeschrieben werden.

Link to post
Die daten werden doch in derselben reihenfolge ausgelesen wie sie reingeschrieben werden.

Aber mit anderer Geschwindigkeit. Die Zeit für das Füllen hängt von der Symbolrate des Transponders ab, die Zeit für das Auslesen vom CPU- und Speicher-Takt. Sie ist in der Rechnung vernachlässigbar, d.h. man kann annehmen, dass das erste und letzte TS-Paket im Puffer quasi gleichzeitig verarbeitet werden. Ob und wann und wie lange der Vorgang durch Time Slicing unterbrochen und damit verzögert wird, ist nicht kalkulierbar.

 

Kurz gesagt, der Versuch, aus zwei aufeinanderfolgenden PCRs ein Delta T zu ermitteln und dieses mit dem Delta T der zu synchronisierenden Uhr zu vergleichen, ist hoffnungslos. Die beiden PCRs könnten ja sogar aus ein- und demselben Puffer stammen... trotzdem ist von Interesse, über welchen Zeitraum man mitteln müsste, um den Einfluß des PCR-Jitter vernachlässigbar klein werden zu lassen. Das sollst du ausrechnen. Mach es einfach.

Link to post

Daten werden mit der gleichen rate verbraucht wie sie erzeugt wurden. Jitter ist immer vorhanden. Das ist so in einer STB wie auch im PC. Deshalb ist es ein widerspruch zu behaupten, dass es in einer STB funktionieren kann, nicht aber in einem PC. Rechenaufgaben kannst du im nachhilfeunterricht lösen lassen.

Link to post

Ok, vergiss es. Außer parasitärem Eunuchengeschwätz ("wissen wie es geht, aber selbst nicht können") hast du offenbar zu diesem Thread nichts beizutragen.

 

Zur Implementation. Die Idee ist, eine im PC vorhandene Hardware-Uhr als Grundlage zu nehmen und gemäß der PCR zu korrigieren. In der Basisimplementation von IReferenceClock ist das die Systemzeit (Link), oder genauer gesagt die via timeGetTime ermittelte Zeit TH, wobei die Präzision mit timeBeginPeriod auf den bestmöglichen Wert (max. 1 ms) gesetzt wird.

 

Bei der Initialisierung wird die Zeit TH0 festgehalten; die später von IReferenceClock zu einem Zeitpunkt TH angegebene Zeit ist immer T = TH - TH0 (also relativ zum Zeitpunkt der Initialisierung).

 

Zu einem Zeitpunkt TP0 trifft aus dem DVB-Datenstrom der erste PCR-Wert P0 ein, dann weitere PCR-Werte PN zu Zeitpunkten TPN. Damit lassen sich Abweichungen zwischen den Zeitspannen TPN - TP0 und PN - P0 feststellen und Korrekturen an der von IReferenceClock gelieferten Zeit T vornehmen.

 

Festzuhalten bleibt jedoch, dass sich im PC auf Anwendungsebene nicht feststellen lässt, wann Datenpakete mit PCR effektiv eingetroffen sind - die Treiber der DVB-Geräte liefern diese Information nicht. Durch Pufferung und weitere Faktoren kann es erhebliche, ständig schwankende Abweichungen zwischen dem tatsächlichen und dem mit der Hardware-Uhr gemessenen Zeitpunkt TPN geben. Man erhält also einen entsprechenden Jitter.

 

Mit wachsendem N bzw. wachsender Differenz TPN - TP0 wird der Jitter-Einfluss prozentual immer kleiner. Nach einer hinreichend langen Zeitspanne fällt er kaum noch ins Gewicht. Damit stellen sich folgende Fragen:

 

- Ab welcher Zeitspanne TPN - TP0 sind die Werte hinreichend aussagekräftig für Korrekturzwecke?

 

Dies hängt von verschiedenen Faktoren ab - dazu gehört die vom DVB-Gerät gelieferten Datenrate und die Pufferung durch den Treiber, sowie die aktuelle Systemauslastung. Also einige Unwägbarkeiten... man kann praktisch nur eine Abschätzung vornehmen.

 

- Mit welcher Formel lässt sich aus T, TPN - TP0 und PN - P0 auf sinnvolle Weise eine korrigierte Zeit TK berechnen?

 

Einfach die Abweichung zwischen PCR und Hardware-Uhr hinzuzuaddieren

 

TK = T + (PN - P0) - (TPN - TP0)

 

bringt es nicht, da so der Jitter voll zur Wirkung kommt. Besser wäre ein Korrekturfaktor

 

F = (PN - P0 ) / (TPN - TP0)

 

der mit steigender Wiedergabedauer immer genauer wird, weil der Jitter-Einfluss auf den Quotienten abnimmt. Wenn die Korrektur ab dem Zeitpunkt TP0, an dem die erste PCR empfangen wurde, berechnet werden soll, sieht es so aus:

 

TK = TP0 + (T - TP0) * F

 

oder vollständig

 

TK = TP0 + (T - TP0) * (PN - P0) / (TPN - TP0)

 

Soweit meine Überlegungen... kann das so gehen? Oder irgendwie noch besser?

Link to post
Bei einem Sender, der einen Sinusdauerton ausstrahlt (Hotbird 10775 H, Bars and Test Tone +4.0 dBu), sind sowohl die Pausen

Das ist mal ein interessanter Test. Da hört man die Pause in der Tat relativ gut.

 

als auch die Tonhöheschwankungen bei Frequenzanpassung hörbar.

Ich habe das gerade mit WatchTVPro getestet. Da springt die Frequenz in 75 Hz Schritten. Bei bis zu +/- 150 Hz höre ich gar keinen Unterschied beim Springen. Da liegt dann aber die Grenze. Springt er von -150 Hz auf -225 Hz oder zurück hört man den Unterschied recht deutlich. Meist bewegt er sich bei mir aber bei +/- 150 Hz. Die Sprünge sind recht selten.

 

So, jetzt klingeln mir die Ohren erstmal...

Edited by CiNcH
Link to post
Meist bewegt er sich bei mir aber bei +/- 150 Hz. Die Sprünge sind recht selten.

Bei pFlags = 0 im DVBSource sind die Sprünge hier leider häufig und größer. Deshalb scheint mir das Rate Matching anhand der Audio-Datenrate nicht optimal zu sein, und deshalb die obigen Überlegungen zu einer Implementation von IReferenceClock. Mit Default WaveOut kann ich das Rate Matching hier ganz vergessen - funktioniert offenbar nicht und führt zu Tonstörungen.

 

Allerdings weiß ich nicht, ob das Rate Matching der Audiorenderer von MS für alle gleich implementiert ist, oder ob es vom Treiber bzw. der Soundkarte abhängt. Das bleibt noch festzustellen.

 

Außerdem ist mir nicht klar, ob die Frequenzänderungen auch die vom Audiorenderer gelieferte Reference Clock beeinflussen, also schneller oder langsamer gehen lassen. Es liegt natürlich nahe, die Uhr der Soundkarte als Basis für eine eigene, PCR-korrigierte Variante zu verwenden. Doch wenn die Soundkarten-Uhr durch Korrekturen anders geht, gibt das eine Rückkopplung, die alles durcheinanderbringt. Aus Sicht des Audiorenderers hat er es dann mit einer "Graph Clock" und nicht seiner eigenen zu tun. Dass er selbst die Basis liefert, weiß er ja nicht...

Link to post

Das ist ja interessant. Ich hatte ja in meiner 'Analyse Ruckelproblem' bereits vor einiger Zeit geschrieben, dass es mit VMR Renderless im TT-Viewer/DVBSHOP.TVplayer nicht zu den Rucklern kam. Ich teste nun gerade wieder und habe schon einen riesen Haufen an Daten. Der Audio Dekoder scheint dabei auch eine wesentliche Rolle zu spielen, dazu aber mehr, wenn ich meine Tests abgeschlossen habe.

Was mir nun beim TT-Viewer aufgefallen ist, dass der Slaving-Modus im Audio Renderer auf 'Graph Clock' steht, die Frequenz wurde bislang aber noch nicht geändert (bleibt konstant bei 48 kHz, siehe Screenshot). So wie es aussieht, wird aber der Fehler (in ms) immer größer, was das nun bedeutet, weiß ich nicht.

 

Wenn ich im GraphStudio zum Remote Graph verbinde, ist die Uhr auf dem Audio Renderer nicht gelb hervorgehoben. Aber auch sonst sehe ich nirgends eine aktive Uhr im Graph!? Ich habe den DVBSource deregistriert. Es wird also die relativ alte Version des DVBSource-Filters im TT-Viewer verwendet.

 

renderless.jpg

 

[EDIT]

So jetzt hat sich doch mal was getan. Die Frequenz wurde geändert und der Fehler wohl korrigiert. Wird also wohl doch synchronisiert. Aber auch hier bewegt es sich in einem Rahmen wie bei WatchTVPro, sprich seltene kleine Sprünge.

 

Ich habe keine Ahnung was die DVBViewer Mini-App hier anders macht, was für eine Uhr hier verwendet wird und wie sie die Wiedergabe scheinbar perfekt hincheatet, sowohl Video als auch Audio, das kommt wirklich locker an eine STB heran, auch über einen langen Zeitraum hinweg. Da steckt glaub einiges dahinter. Wahrscheinlich kann Christian hier einiges mehr dazu sagen...

Edited by CiNcH
Link to post

Dann kann es nur diese Uhr sein:

 

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

 

Wenn ich sie im DVBViewer GE herbeizitiere und per IMediaFilter.SetSyncSource dem Graphen unterschiebe, sieht er wie oben beschrieben aus. Mit einem Unterschied: Der Audiorenderer-Modus ist "Live Graph Clock", nicht "Graph Clock". Liegt an pFlags = 0 im Gegensatz zu AM_PUSHSOURCECAPS_NOT_LIVE im DVBSource-Filter des TT-Viewers.

 

Ob Christian das so gewollt hat, ist eine andere Frage :huh: Könnte sein, dass der Filtergraph-Manager die Systemuhr selbst gewählt hat, weil der TT-Viewer im Gegensatz zum DVBViewer Pro/GE nichts vorgibt. In meinem System macht er es in dem Fall auch.

Link to post

Jedenfalls habe ich nie eine perfektere Wiedergabe gesehen (perfekt flüssig und synchron) und das auch über einen langen Zeitraum hinweg.

Aber bei Lars soll das ganze ja nicht so gut funktionieren. Vielleicht hat der eine "schlechtere" Uhr!?

Edited by CiNcH
Link to post

Der FireDTV-Viewer hat diese Graph-Clock auch, ich kann es nur mit TV nicht testen. hab keine FireDTV.

Und bei der Datei-Wiedergabe sagt es ja nicht viel aus.

Link to post

Im "Live Graph Clock"-Modus (also Systemuhr plus DVBViewer Filter, der sich als Live Source ausweist) regelt der Audiorenderer die Sache hier relativ gut, d.h. die Frequenz schwankt nicht so häufig und nicht so sehr, Pausen bleiben aus. Gemäß

 

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.

erfolgt eine Synchronisation mit den Zeitstempeln der Audio-Samples, und da diese aus dem DVB-Transportstream stammen, bedeutet es auch indirekt eine Synchronisation mit der PCR (also der Uhr des Senders), sofern nicht der Audiodecoder noch dran herumschraubt...

Link to post

Gibt es denn für "Ottonormalverbraucher" also jemand, der sich mit der direkten Einzelheiten nicht so aus kennt (wie mich :) ) einen Lösungsansatz gegen die Tonaussetzer? Schön wäre, wenn es die Spezies hin bekommen würden.

 

Gruß Eichhorn

Link to post

Ich würde ehrlich gesagt die AC3Filter-Konfiguration nochmal überdenken, wenn ich dich wäre.

 

Sag doch mal mehr zu den Tonaussetzern. Sind die immer drin oder nur zeitweise? Und wie lange und in welchen Abständen?

Edited by CiNcH
Link to post

Irgendwo, ich weiß jetzt nicht ob es hier im Forum war oder in einem anderen, wurden diese Einstellungen empfohlen. Ich war eigentlich bisher ganz zufrieden damit. Irgendwie sind mit dieser Einstellung die Lautstärkeunterschiede zwischen AC3 Ton und Stereo nicht so stark. D.h. sie fallen eigentlich gar nicht auf.

 

Die Tonaussetzer fangen erst nach einer Weile an. Wie weiter oben schon beschrieben, sinkt bei mir die Völle des Puffers ganz langsam und dann geht es los. Gestern z.B. habe ich ca. 1,5 Stunden fern gesehen und habe keinen bemerkt. Allerdings waren unter DirectSound Device laut Anzeige Pausen vorhanden und kein Ton stand auch auf ein paar Millisekunden. Demzufolge waren Tonaussetzer da, welche ich nicht bemerkt habe. Ich kann nicht sagen in welcher Regelmäßigkeit diese Aussetzer kommen, es ist immer unterschiedlich. Ich hatte doch weiter oben geschrieben, dass wenn ich einen Sender sehe und kurz auf Pause gehe und dann wieder abspiele, also per Timeshift von HDD sehe steht der Puffer konstant bei 90% und es gibt keine Probleme. Gestern allerdings hatte ich zum 1. Mal, dass der Puffer bei dieser Betriebsart so stark schwankte, dass es nicht "hörbar" war. Dagegen half nur ein Neustart des DVBViewer und es lief wieder wie Butter. Reproduzieren konnte ich diesen Zustand allerdings nicht.

 

Ich habe einen Latency von ca. 700 eingestellt.

 

Veröffentlicher doch einfach mal deine empfohlenen AC3 Filtereinstellungen. Ich bin sicher nicht der Einzige, der daran interessiert ist.

 

Gruß Eichhorn

Edited by Eichhorn
Link to post
Irgendwie sind mit dieser Einstellung die Lautstärkeunterschiede zwischen AC3 Ton und Stereo nicht so stark. D.h. sie fallen eigentlich gar nicht auf.

Ja, weil du immer einen 5.1 Upmix machst. Da du über S/P-DIF fährst musst du das dann wieder in AC3 kodieren, weil man 5.1 PCM nicht über S/P-DIF übertragen kann.

 

Die Tonaussetzer fangen erst nach einer Weile an. Wie weiter oben schon beschrieben, sinkt bei mir die Völle des Puffers ganz langsam und dann geht es los.

OK, dann wart mal etwas. Wir testen gerade verschiedene Ansätze..

Link to post

Es kommt immer auf die Audioanlage bzw. Verkabelung an und was man alles wie ausgeben will. Da ich PCM ausgebe, sind die Einstellungen bei mir komplett anders als bei dir. Deine Einstellungen leuchten mir schon ein, aber das ist halt schon eine komplexe Kette. Warte einfach etwas. Es wird wahrscheinlich ein anderer Synchronisationsansatz im DVBViewer kommen.

Link to post
  • 1 year later...

Hy,

gibt es jetzt schon einen neuen Ansatz für das Thema? Ich habe weiterhin leider Tonaussetzer...diese können aber auch erst nach 45 Minunten beispielsweise auftreten... Use DVBClock bringt leider auch keine Besserung!

 

DANKE

LG

Sascha

Link to post
  • 2 months later...

Hallo

Ich greife das Thema nochmal auf.

Ich habe das gleiche Problem, nämlich dass nach ca. 45 Minuten bei Sky-HD Sendern ein Ton-Wirrwarr entsteht. Es erinnert mich irgendwie an einen Pufferüberlauf. Wenn ich nun kurz auf einen anderen Sender wechsle und dann wieder zurückschalte, läuft alles perfekt weiter. Ich benutze AC3Filter aber auch unter dem FFDShow-Filter tritt das gleiche Phänomen auf. Irgendwie scheint es also direkt mit dem DVBViewer zu tun zu haben.

Ein ähnliches Problem besteht bei Sky-SD Sendern die auch AC3 senden. Schalte ich einen derartigen Sender ein, aber ersteinmal auf den mit Stereo-Signal, läuft alles gut. Wähle ich aber dann die DD-Tonspur stottert der Ton von Beginn an. Wenn ich aber über die Senderliste, also die, die per Maus auswählbar ist direkt den Sender mit der AC3-Spur anklicke, funktioniert alles bestens.

Ich hoffe ich hab mich verständlich ausgedrückt und jemand kennt eine Lösung.

Gruß Frank

Link to post

Ich will ja nicht ungeduldig erscheinen...

aber bei fast 3000 Hits scheint das Problem nicht nur bei mir zu bestehen.

Ich bin Super zufrieden mit dem DVBViewer und möchte Ihn nie mehr missen, aber wenn mir hier noch jemand eine Lösung anbieten könnte, wäre es nahezu perfekt...

Link to post

Ist nun doch schon eine ganze Weile her, wo das Problem bei mir bestand. So ganz genau weiß ich gar nicht mehr ab wann das Problem bei mir weg war. Auf jeden Fall habe ich meine Soundkarte aus gebaut und mir bei Gigabyte ein zusätzliches Teil bestellt, damit ich über die OnBoard Soundkarte per SPDIF ausgeben kann. Weiterhin gab es damals glaube im DVBViewer noch nicht die Audio A/B Umschaltung. Ich gebe bei Audio A per Spdifer direkt an den optischen Ausgang aus. Wenn keine 5.1 Sendung läuft, nutze ich zur Soundausgabe ganz einfach meinen Fernseher per HDMI. Eingestellt habe ich bei Audio B für AC3 den AC3 Filter, für Stereosender den ffdshow Filter. Ich weiß jetzt nicht mehr, seit wann das mit den Tonaussetzern bei mir weg ist, es ist jedenfalls weg.

 

 

EDIT: war nicht ganz richtig Audio B über HDMI MP2 und AC3 AC3 Filter Ausgabe Audio A (SPDIF) MP2 ffDshow und AC3 Spdifer

Edited by Eichhorn
Link to post

Join the conversation

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

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