mpcor - Minphasenfilter für TV

Ulis Mess- und Korrekturprogramm
Stanley
Aktiver Hörer
Beiträge: 193
Registriert: 27.05.2014, 18:28
Wohnort: CH-Uster

mpcor - Minphasenfilter für TV

Beitrag von Stanley »

Hallo zusammen

Ziel ist: Den TV Ton über RME - JRiver UC - Acorate Convolver 8-kamnalig undlippensynchron zu hören.

Der erste Schritt war den TV-Ton über den optischen Toslink ins RME UC zu bringen und dann mittels Loopback ins JRiver. Im JRiver wiederum über Live-In und über den AC 8-kanalig zu hören. Das habe ich hingekriegt. Ein Stolperstein war hier das "Chanel Offset", auf Deutsch "Kanalausgleich". Es läuft nun, aber natürlich nicht Lippensynchron.

Also habe ich alle aktuellen corxL/R48.dbl in einen Ordner kopiert. Dann im Menü Room aus diesen Filter mpcorxL/R.dbl generiert und anschliessend daraus die .cpv für den Acourate Convolver.

In Acourate habe ich mir die neuen Filter angeschaut. Sie sind in der Amplitudenansicht fast deckungsgleich. In der Time Domain sind die Maxima fast bei Null und die Originalfilter bei ca. 0,7 (Sekunden?).

So weit so gut. Nur wenn ich nun mit diesen Filter fernsehe, ist die Zeitdifferenz immer noch sehr gross, gefühlsmaässig würde ich sogar sagen, dass sich wenig bis nichts getan hat.

Ich habe die Tondiffernz beim Fernseher auf 0 gestellt (80ms waren dort Standard).
Die Latenz im RME von 1024 auf 256 gestellt.
Die Buffer im AC so weit zurückgenommen wie es noch ging.

Habe ich irgendwo einen Fehler gemacht?
Gibt es noch andere Stellschrauben?

Hat schon jemand mit diesen mpcor.... gearbeitet, ähnliches wie ich erlebt, aber eine Lösung gefunden?

Bin dankbar für Hinweise.

Heinz
Bild
Dipolaktiv
Aktiver Hörer
Beiträge: 63
Registriert: 24.11.2019, 11:48
Wohnort: Zürich

Beitrag von Dipolaktiv »

Hallo Heinz

ev. ist es genau dieses Feature was die lösung ist.

https://wiki.jriver.com/index.php/Lip_Sync

habs nie probiert.

Gruss

Peter
Bild
Stanley
Aktiver Hörer
Beiträge: 193
Registriert: 27.05.2014, 18:28
Wohnort: CH-Uster

Beitrag von Stanley »

Hallo Peter

Das verstehe ich nicht so, denn JRiver weiss nichts von Video, wenn nur Audio läuft. Hat also keinen Anhaltspunkt auf was es synchronisieren soll. Das funktioniert meiner Meining nach nur, wenn das Video über JRiver läuft.
Also muss ein Film, Video etc. mit Tonspur über JRiver laufen. Dann kann die Bild und Audio-Spur synchronisiert werden.

In unserem Fall müsste ja die Audiospur früher abgespielt werden. Das geht doch nur, wenn das Bild verzögert wird. Somit: Keine synchronisation von Bild und Ton in JRiver, ohne dass das Bild auch über JRiver kommt.

Gruss

Heinz
Bild
chriss0212
Aktiver Hörer
Beiträge: 3733
Registriert: 06.01.2015, 21:03
Wohnort: Wuppertal

Beitrag von chriss0212 »

Bild
Stanley
Aktiver Hörer
Beiträge: 193
Registriert: 27.05.2014, 18:28
Wohnort: CH-Uster

Beitrag von Stanley »

Hallo Chriss

Danke für den Link. Einen Teil der Sachen habe ich jedoch bereits im Vorfeld schon gelesen.
Was mich stutzig macht ist die Tatsache, dass alle Massnahmen, die ich gemacht habe, keinen merkbaren Einfluss genommen haben. Ich ging davon aus, dass die ca. 0,7 Sekunden, um die die Filter nach vorne geschoben werden, am Ende auch mit 0,7 sec früherem Ton korrespondieren müssten. Deshalb auch meine Frage, ob ich denn etwas falsch gemacht habe. Ich glaube nicht. Zu beachten ist auch, dass ich mit 8 Kanälen höre. Mein NUC mit i5 geht bei 48kHz und FFT <16k zeitweise über 50% Belastung (Echtzeit).

Früher benutzte ich den Convolver von JRiver. Der braucht effektiv viel weniger Zeit für die Berechnungen als z. B. der AC. Nur die Fummelei mit der Syntax, die fehlende Möglichkeit zum direkten Umschalten von Filtern (oder geht das heute?), kein FLOW etc., hält mich davon ab das Ding wieder zu verwenden. Insbesondere auch deshalb, weil ich es höchst selten überhaupt vermisse den TV-Ton ohne Convolution hören zu müssen. Also werde ich deshalb keinen riesigen Aufwand machen. Zur Zeit bin ich ja sowieso am Optimieren meiner Frequenzweichen und Filter. Vielleicht, wenn ich irgendwann zufrieden bin mit Weiche und Filter, versuche ich es noch einmal.

Schlussendlich habe ich einfach probiert Audio von einer anderen Quelle als vom NAS, also aus TV, Phono oder Handy, über das RME und dann über das Live-In von JRiver laufen zu lassen. Das funktioniert ja wie mitgeteilt. Bei Phono spielt dann die Latenz auch keine Rolle mehr.

Ich gehe nun davon aus, dass bei 2 Kanälen die Synchronisation besser klappen würde. Die Rechen- und Bufferzeit bei 8 Kanälen ist jedoch zu gross. Trotzdem interessiert mich natürlich an was es denn genau liegt, dass die 0.7 sec nicht greifen.

Grüsse

Heinz
Bild
uli.brueggemann
Aktiver Hersteller
Beiträge: 4076
Registriert: 23.03.2009, 15:58
Wohnort: 33442
Kontaktdaten:

Beitrag von uli.brueggemann »

1. Linearphasige Filter sind symmetrisch. Sie verursachen daher prinzipbedingt eine Latenz von halber Filterlänge / Abtastrate. Will man diese Latenz vermeiden, so muss man minimalphasige Filter nehmen, die ihrerseits aber nicht die Exzessphase korrigieren (im üblichen Verständnis also lediglich den Frequenzgang)

2. Die meisten Faltungsalgorithmen verwenden eine einheitliche Partitionierung der Datenblöcke, so auch z.B. AcourateConvolver, JRiver, Roon. Hierdurch entsteht eine Latenz mit der doppelten Blockgröße / Abtastrate. Im Prinzip ist es also gewünscht, die Blockgröße so klein wie möglich zu machen. Schaut man sich dabei aber die CPU-Last an, stellt man fest, dass die Last mit kleinen Partitionen stark ansteigt. Im übrigen auch bei zu großen Partitionen. Die Kurve dazu ist quasi eine Badewannenkurve, es gibt irgendwo ein Optimum, leider mit entsprechender Latenz.
Beim AC wird die Puffergröße mit dem Parameter FFTsize festgelegt.

3. Die Partitionspuffer müssen gefüllt sein, damit die Faltung stattfinden kann (entsprechendes gilt auch für das Auslesen). Wie oft der Partitionspuffer beschrieben wird hängt wiederum auch vom Asio-Puffer ab. Ist dieser zu klein, so findet wiederum eine ständige Unterbrechung der Datenverarbeitung statt, die CPU-Last steigt wiederum. Wenn nun z.B. FFTsize den Wert 32768 hat, dann erfolgt das Befüllen mit 512 x 64 auch nicht schneller als mit 16 x 2048. Letzteres bedingt weniger CPU-Last.

4. Im Rahmen einer Echtzeitverarbeitung will man klar eine kleinstmögliche Latenz. Also bei Live-Anwendungen auf Bühne, am Mischpult und eben auch beim Video mit dem Lipsync-Aspekt. Die Strategie ist hier dann:
a) minimalphasiges Filter
b) Filter so kurz wie möglich. Bei Video beschäftigt das Bild das Gehirn, es hat weniger Kapazitäten hinsichtlich Audio-Qualität. Man kennt es andersherum: wer hat nicht schon beim intensiven Musikhören die Augen geschlossen?
c) Verkürzen der Partitionsgröße unter Berücksichtigung der CPU-Last
d) sinnvolles Anpassen der Größe des Asio-Puffers

5. Falls eine Software Bild und Ton verarbeitet und damit auch das Bild kennt, kann sie evtl. das Bild verzögern. Bei JRiver klappt das auch mit linearphasigen Filtern. Wird dagegen dem Convolver lediglich ein TV-Ton zugespielt müssen die Maßnahmen a)-d) ausgeführt werden.

6. Zuletzt gibt es noch Faltungsalgorithmen mit nicht-einheitlicher Partitionsgröße (non-uniform partitioned convolution). Als Convolversoftware kenne ich hier SIR3 (bzw. SIR2), Voxengo Pristine Space und für Linux jconv. Zur Frage der optimalen Partitionsgrößen und Verarbeitung per Multithreading gibt es eine Reihe von wissenschaftlichen Arbeiten. Ich bin da wohl zu alt für, das geht tief ins Optimieren von parallelen Algorithmen. Spätestens bei Mehrwege-Systemen wird es absolut kniffelig, vor allem wenn dann eine variable Anzahl von CPU-Kernen vorhanden ist. Vielleicht schreibt mal jemand eine Software-Library.

Grüsse
Uli
Bild
Dipolaktiv
Aktiver Hörer
Beiträge: 63
Registriert: 24.11.2019, 11:48
Wohnort: Zürich

Beitrag von Dipolaktiv »

Stanley hat geschrieben:
03.09.2020, 22:00
Hallo Peter

Das verstehe ich nicht so, denn JRiver weiss nichts von Video, wenn nur Audio läuft. Hat also keinen Anhaltspunkt auf was es synchronisieren soll. Das funktioniert meiner Meining nach nur, wenn das Video über JRiver läuft.
Also muss ein Film, Video etc. mit Tonspur über JRiver laufen. Dann kann die Bild und Audio-Spur synchronisiert werden.

In unserem Fall müsste ja die Audiospur früher abgespielt werden. Das geht doch nur, wenn das Bild verzögert wird. Somit: Keine synchronisation von Bild und Ton in JRiver, ohne dass das Bild auch über JRiver kommt.

Gruss

Heinz
Hallo Heinz

mit Jriver kannst auch Video wiedergeben. Was ich nicht weiss wie gewöhnliches Fernsehen geht. Also SRF, ARD etc.

Gruss

Peter
Bild
Stanley
Aktiver Hörer
Beiträge: 193
Registriert: 27.05.2014, 18:28
Wohnort: CH-Uster

Beitrag von Stanley »

@Uli
uli.brueggemann hat geschrieben:
04.09.2020, 09:18

.....

4. Im Rahmen einer Echtzeitverarbeitung will man klar eine kleinstmögliche Latenz. Also bei Live-Anwendungen auf Bühne, am Mischpult und eben auch beim Video mit dem Lipsync-Aspekt. Die Strategie ist hier dann:
a) minimalphasiges Filter
b) Filter so kurz wie möglich. Bei Video beschäftigt das Bild das Gehirn, es hat weniger Kapazitäten hinsichtlich Audio-Qualität. Man kennt es andersherum: wer hat nicht schon beim intensiven Musikhören die Augen geschlossen?
c) Verkürzen der Partitionsgröße unter Berücksichtigung der CPU-Last
d) sinnvolles Anpassen der Größe des Asio-Puffers

........

Grüsse
Uli
Entsprechend den Punkten habe ich herumgespielt.
Zerst mit minimalphasigen Filter 32k. Da komme ich gar nicht in die Nähe von Lippensynchronität.

Also die Filter nochmals verkleinert, auf 16k. Aber auch das reicht noch nicht aus.

Nächster Versuch mit Filter der Grösse 8k. Mit CPU-Last und Echtzeit um ca. 30%. ASIO Puffergrösse und FFT optimiert. Pufferzeit und Rechenzeit zusammen bei ca. 120ms. Beim Fernseher die Tonverzögerung von 80 af Null gestellt. Reicht aber immer noch nicht. Die Skala im Fernseher geht von 0 bis 250. Dachte dies seien ms, sind es aber nicht.

Ich denke, dass es mit Filter der Grösse von 4k zu machen ist. Im Moment habe ich das aber noch nicht probiert. Mache ich später. Ob mit 4k das überhaupt noch Sinn macht, werde ich dann sehen.

@Peter

Falls Filme/Video und/oder TV über JRiver laufen, kann dort sehrwahrscheinlich mit dem von Dir angegebenen Link in JRiver der Ton und das Bild synchronisiert werden. Nur, ganz offen gesagt, habe ich absolut keine Lust JRiver für mehr als Audio zu benutzen. Ich bringe es nicht einmal hin Radio über JRiver zu hören. JRiver gibt den Ton nicht an ASIO von Acourate, wie eigentlich definiert, aus.

Grüsse

Heinz
Bild
chriss0212
Aktiver Hörer
Beiträge: 3733
Registriert: 06.01.2015, 21:03
Wohnort: Wuppertal

Beitrag von chriss0212 »

Hallo Heinz
Zerst mit minimalphasigen Filter 32k. Da komme ich gar nicht in die Nähe von Lippensynchronität.
Dann vermute ich, Du machst etwas falsch.

Vielleicht kannst Du mal die Schritte aufzählen, die Du machst!

Ach ja: sicher, das der Ton zu späht kommt und nicht das Bild? Heute Fernseher haben relativ viel Delay, und wenn Du den Ton vorher abgreifst, ist es eher das Bild, was zu späht kommt.

Grüße

Christian
Bild
Buschel
Aktiver Hörer
Beiträge: 846
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitrag von Buschel »

Hallo Heinz,

irgendwie passen die Teile wie von dir beschrieben für mich noch nicht zusammen. Wenn du minimalphasige Filter einsetzt, bestimmt eigentlich nicht die Filterlänge den Zeitversatz, sondern die Partitionsgröße. Bei gleichbleibender Partitionsgröße nimmt mit längeren Filtern nur die CPU-Last zu. Was genau hast du denn jetzt in Summe eingestellt?
- Samplingfrequenz
- Filterlänge
- Partitionsgröße
- Anzahl Kanäle
- Größe von RME / ASIO Buffer

Und verstehe ich richtig, dass du den Ton direkt am TV abgreifst? Das ist gegenüber Abgreifen über ein externes Geräte nachteilig, weil so die typische TV-Verzögerung von vielen ms nicht ausgenutzt werden kann.

Bei meinem i3 NUC stelle ich etwa 120ms Verzögerung (BDP zu TV) ein. Das geht für zwei Kanäle mit sehr wenig Last. Für mehrere Kanäle wird das aber mit Sicherheit eine Herausforderung.

Grüße,
Andree
Bild
Stanley
Aktiver Hörer
Beiträge: 193
Registriert: 27.05.2014, 18:28
Wohnort: CH-Uster

Beitrag von Stanley »

Guten Abend zusammen

- Samplingfrequenz Per Toslink 48kHz
- Filterlänge Von der Standardlänge bis runter auf 8k (Versuch mit 4k wird folgen)
- Partitionsgröße Zusammen mit ASIO Buffer verändert*
- Anzahl Kanäle 8
- Größe von RME / ASIO Buffer Zusammen mit Partitionsgrösse verändert*

*Die beiden Werte habe ich jeweils einzeln verändert. Die Werte für die CPU-Last und der Echtzeitindex sollten nicht über 50% gehen.

Die Tendenz ist ja auch ersichtlich gewesen. Je kleiner die Filter, desto kleiner wurden die Zeiten für das Befüllen der Buffer und die Faltungszeit.

Wären es nur 2 Kanäle, dann denke ich, dass Filter mit 32k bereits ausgereicht hätten. Also 32k:8=4k.

Muss schauen, wann ich da weiter machen kann.
Berichte dann hier.

Grüsse

Heinz
Bild
chriss0212
Aktiver Hörer
Beiträge: 3733
Registriert: 06.01.2015, 21:03
Wohnort: Wuppertal

Beitrag von chriss0212 »

Hallo Heinz

Bitte beschreibe doch mal alle Schritte, die Du in Acourate machst.

Ich vermute, du erstellst keine minimalphasigen Filter sondern linearphasige.

Ansonsten passt das wie André auch schreibt nicht zusammen.

Grüße

Christian
Bild
Stanley
Aktiver Hörer
Beiträge: 193
Registriert: 27.05.2014, 18:28
Wohnort: CH-Uster

Beitrag von Stanley »

Hallo Chriss

Zuerst habe ich die originalen Filter genommen, in der Form xx48.dbl, mit denen ich schlussendlich als xx48.cpv Musik höre und mache daraus Minphasenfilter. Siehe Room "Special Convert Filters to Minphase".

Dann kürze ich jeden der 8 Filter mit Cut'N Window auf z. B. 8192. Einstellungen in Cut'N Window sind: Position/Count = 0. peak symmetric aktiviert und Start Position ist aktiviert.

Dann mache ich mit "Create CPV for AC" aus Room die Filter, die ich dann im AC verwende. Die Filter funktionieren ja auch.

Da erkenne ich keinen Fehler. Die Einstellungen im Cut'N Window sollten auch richtig sein.

Chriss, es liegt meiner Meinung nach tatsächlich an der Bufferzeit und den Einstellungen der FFT und Buffergrösse. Die ist eben so lang, da es 8 Kanäle sind

Gruss

Heinz
Bild
Buschel
Aktiver Hörer
Beiträge: 846
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitrag von Buschel »

Hallo Heinz,

das hört sich für mich erstmal richtig an. Dein Problem ist, dass du eigentlich mit Null-Delay aus dem Prozess herauskommen musst, weil du direkt aus dem TV dein Audiosignal bekommst. Das erzwingt eine geringe Partitionsgröße und damit hohe Rechenlast, die wiederum wird verschlimmert durch die vielen Kanäle. Das wiederum zwingt dich zur Reduktion der Filterlänge.
Bei der hohen Last von 50% braucht dein NUC nach meinem Verständnis als Vorlaufzeit etwa 50% der zur Partitionsgröße passenden Zeit. Beispiel: Der Block einer 1024er Partition dauert bei 48 kHz 21,3 ms. Wegen overlapp-add geht diese Länge doppelt in die Verzögerung ein, macht also 42,7 ms. Die Berechnung eines 1024er Blocks bei 50% Last dauert 10,7 ms, d.h. das Gesamtdelay für die erstmalige Wiedergabe ist etwa 53.3 ms. Dazu kommt noch das Delay für ASIO/RME und das vom RME selbst erzeugte Delay für I/O.

Mit welcher Partitionsgröße und welchem ASIO/RME Puffer läuft es denn jetzt?

Musst du das Signal am TV abgreifen oder kannst du es an einem zuspielenden Gerät bekommen (z.B. SAT-Receiver oder BPD)? Aus Sicht der Korrektur ist das die beste Lösung, weil du dann längere Delays einstellen kannst, da der TV das Bild und den Ton verzögert.

Grüße,
Andree
Bild
chriss0212
Aktiver Hörer
Beiträge: 3733
Registriert: 06.01.2015, 21:03
Wohnort: Wuppertal

Beitrag von chriss0212 »

Hallo Heinz
Musst du das Signal am TV abgreifen oder kannst du es an einem zuspielenden Gerät bekommen (z.B. SAT-Receiver oder BPD)? Aus Sicht der Korrektur ist das die beste Lösung, weil du dann längere Delays einstellen kannst, da der TV das Bild und den Ton verzögert.
Jupp... das wäre die beste Lösung!

Grüße

Christian
Bild
Antworten