Einstieg in Acourate

[manollo139]

Ja ich kenne die minimalPhasigen Filter!
Allerdings hatte Herr Brüggemann mal vom JConvolver gesprochen, dieser soll mit etwas mehr Rechenpower die Delayzeiten noch mehr drücken können, wenn ich Ihn da richtig verstanden habe.

[udo993]

Ohne den Jconvolver jetzt wirklich zu kennen. Es wird wohl über die Partitionsgröße gehen. Die lässt sich bei JConvolver auch(genau wie bei Brutefir) einstellen.

Vielleicht hilft das hier:

http://jcgui.sourceforge.net/

Ich versuchs mal zu erklären aber vorsicht Halbwissen.
Hast du einem Filter mit einer Länge von 65536 Samples ergibt sich das oben genannte Delay von 0,683s bei 48khz.(Peak in der Mitte bei Sample 32768).
Jetzt kann man den Filter in Partitionen aufteilen. Gibt man z.b. in der Konfig von Brutefir 65536/16 an bei Filterlänge wird der Filter in 16x4096sample große Partitionen aufgeteilt. Das hat zur folge das ein Durchlauf nicht mehr 0,683s dauert sondern nur noch 0,042s(Peak bei Sample 2048).

Jetzt kanns du probieren wann deine CPU ans limit kommt in dem du die Partitinsgröße immer kleiner machst bzw. die Anzahl größer. Aber vorsicht der Speicherbedarf und die Rechenlast geht dabei rasant nach oben zumindest bei Brutefir. Bei 65536/64 und 2 Kanälen ist mein PentiumM 1,6Ghz 1Gb Ram an der Schmerzgrenze.

Ein PentiumM oder Core duo sind eigentlich Krüppel was solche Berechnungen angeht. Ein SHARC Prozessor lacht sich darüber kaputt. Aber der kann dafür nichts anderes

Gruß Udo

[manollo139]

Mhm guter hinweis, das wird in den nächsten tagen getestet!

[Uli.Brüggemann]

Also, ich glaub ich sollte hier mal etwas zur Aufklärung beitragen:

Nehmen wir ein minimalphasiges und ein linearphasiges Filter. Einfach einen Dirac-Puls, alle anderen Samples = 0.
Das minimalphasige Filter beginnt mit dem Dirac bei Sample 0. Das linearphasige hat den dirac in der Mitte, bei einem Filter der Länge 65536 taps also bei Sample 32768.

Das linearphasige Filter verursacht hier bereits eine Verzögerung von 32768 Samples, was dann bei 48 kHz einer Zeit von ca. 0,682 sek entsprechen würde. Beim minimalhasigen Filter wird das Musiksignal dagegen direkt zu Beginn mit dem Dirac gefaltet, was dann zur Verzögerung 0 führt.

Dies wäre alles so, wenn die Faltung im Zeitbereich durchgeführt würde. Was aber bei langen Filtern sehr rechenaufwendig wird.

Demzufolge erfolgt die Faltung typischerweise im Frequenzbereich. Es werden dazu das Musiksignal als auch das Filter per FFT transformiert, die Faltung entspricht einer Multiplikation von komplexen Zahlen, anschliessend wird wieder zurücktransformiert. Wenn ich mich richtig erinnere bietet diese Vorgehensweise ab Filterlängen von 64 taps bereits Vorteile gegenüber der (diskreten) Faltung im Zeitbereich.

Nun hat die FFT-Convolution aber auch ihre Eigenschaften. Eine davon ist, dass man "päckchenweise" faltet. Um z.B. das Musiksignal mit dem 65536 taps-Filter zu falten, müsste man ein Päckchen von 65536 Samples des Musiksignals "sammeln". Dann lassen sich Signal und Filter in einem Rutsch transformieren, multiplizieren und zurücktransformieren, es ergibt sich ein Resultat der Länge 131071 Samples.
Der grosse Nachteil: man muss dann ja warten, bis 65536 Samples des Musiksignals gesammelt wurden, erst dann lässt sich die Transformation rechnen. Es ist dabei egal, ob das Filter selbst minimal- oder linearphasig ist.Bei Minimalphase ergibt sich eine Verzögerung von 1.356 sek, bei Linearphase kommt da noch die Filterverzögerung dazu, also ergibt sich dann eine Latenz von 2.048 sek.

Lösung: es wird mit kleineren Päckchen gerechnet. Bei der sogenannten partitioned convolution sind es Päckchen konstanter Länge. Je kleiner das Päckchen, desto größer die Prozessorbelastung. Mit Brutefir und einer Core2Duo sind 1024 Samples als Päckchengröße gut machbar. Das minimalphasige Filter hat dann 1024/48000=21 ms Verzögerung,beim linearpasigen Filter kommen wiederum die 0,682 sek dazu.

Tja, und bei der non-partitioned convolution (z.B. bei jconvolver) beginnt es mit einem kleinen Päckchen (das benötigte jack hat minimal 64 Samples), welches dann immer größer wird. Wer sich da reinlesen will, kann z.B. http://kokkinizita.linuxaudio.org/papers/aella.pdf anschauen.
Damit ergibt sich theoretisch eine Latenz beim minphase-Filter von 1.3 ms (Schallweg~45 cm !)

Zusammenfassung: die Faltung im Frequenzbereich benötigt Rechenzeit abhängig von der Päckchengröße. Dazu kommt dann noch die Filterlatenz beim linearphasigen Filter dazu.

Und noch etwas: die DSP's a la Sharc tun sich schwer bezüglich großer Filter, was auch am benötigten Speicher liegen mag. Das geht mit den üblichen PC-Prozessoren und Gleitkommarechnung heute viel leichter. Noch flotter geht es mit NVidia-Graphikprozessoren und CUDA, aber das ist dann ein neues Thema.

[manollo139]

Hallo, danke für die sehr sehr gute ausführung zu dem Thema.
So, ich bekomme es bei mir nun mit 2048 Samples hin. Aber das reicht noch nicht ganz um den versatz zu den Rears glattzubügeln.


Gruß Manu