Hallo,
gibt es eine (überschlägige) Formel wo man in Abhängigkeit von
Samplerate, Taps usw. berechnen kann wieviel Rechenpower ein STM32F4
oder F7 bei einem FIR verbraucht?
Es geht einfach darum, ich möchte per I2S einen Audiostream einlesen,
ein FIR Filter darüber legen (wenn es geht so genau wie möglich) und
wieder per I2S ausgeben. Wenn das ausreicht, würde ich auf einen DSP
verzichten der ja ohnehin zum Initialisieren und Übergabe der Parameter
auch einen externen µC benötigen würde.
Eingabe/Ausgabe sollen 24bit mit 48kHz sein. Ein Mono Kanal reicht
vollkommen aus. Wenn das irgendwer schonmal so gemacht hat und kann mir
da eine grobe Hausnummer nennen inwieweit ein F4 oder F7 da beschäftigt
ist, wäre das super.
Danke schonmal!
So Formeln gibt es sicher nicht, aber abhängig von der Ordnung des
Filters kannst du ja leicht rausfinden, wie viele Multiplikationen und
wie viele Additionen du hast. Damit kannst du auch angeben, wie viele
Rechenoperationen du machen musst, pro Sekunde.
Ich würds, da es 24 Bit sein sollen, mit der FPU machen. Sie ist sehr
performant, ich hatte mal 2 Regler für 2 Antriebe damit implementiert,
wo mit 100 kHz abgetastet wurde und der STM hat nur gelacht ? es gibt
eine Appnote, wo anhand der Berechnung eines Fraktals (Juliamenge) die
Anzahl Flops der FPU angegeben wird.
Gruss!
P.S.:
> wenn es geht so genau wie möglich
ist eher eine doofe Spezifikation :-(
FIR schrieb:> STM32F4> oder F7
Hmm soweit ich weiß, hat der F4 schon MAC-Operation in der FPU ... Der
GCC verwendet die dann auch schön, ohne dass man es explizit sagen muss.
Ich würde es ebenfalls mit Floats machen ... Das meiste wird in einem
Taktzyklus abgearbeitet - Divisionen brauchen länger. Bei einem FIR aber
kein Thema :)
Mal so grob überschlagen ...
1024-tap FIR-Filter wären 1024 Multiplikatione + 1024 Additionen ...
Alsos sowas 2048 Taktzyklen hätte ich jetzt gesagt ... Bei sagen wir mal
168Mhz (F4) und 48kHz hätte man zwischen den Samples um die 3500
Taktzyklen Zeit ... Bei Stereo und 2*2048 Taktzyklen würde es schon sehr
eng werden.
Aus diesem Grund verwende ich FIRs nur in FPGAs und IIR nur auf µCs :D
Aber gut, wahrscheinlich sind deine Filter nicht so lang - da hast du
aber keine Angaben gemacht.
Wenn es nicht FIR sein muss, dann schau dir mal die Bi-Quad-IIR-Filter
an ... Die sind mit wesentlich weniger Aufwand zu berechnen und es gibt
einige gute Design-Tools online
zB
http://www.earlevel.com/main/2013/10/13/biquad-calculator-v2/
Muss man aber auf die Stabilität achten, da IIR nicht immer stabil sind
wie FIR.
512 taps sollten reichen. Dann könnte ich ja sogar 96kHz in Erwägung
ziehen :-). Wie schon gesagt, der STM hat sonst keine weiteren Aufgaben.
IIR würden den Frequenzgang vermutlich genauso hinbekommen - ich
benötige aber noch lineare Phase ab sagen wir 300Hz bis zur oberen
Grenze.
FIR schrieb:> 512 taps sollten reichen. Dann könnte ich ja sogar 96kHz in> Erwägung> ziehen :-). Wie schon gesagt, der STM hat sonst keine weiteren Aufgaben.>> IIR würden den Frequenzgang vermutlich genauso hinbekommen - ich> benötige aber noch lineare Phase ab sagen wir 300Hz bis zur oberen> Grenze.
Würde dir auf jeden Fall dann zu FIR raten ... Machen weniger Ärger :)
Man kann auch mehrere IIR-Biquads nehmen (SOS-Struktur) oder einen
Lattice IIR. Bei letzterem ist der Vorteil der, dass die Stabilität
besonders einfach geprüft werden kann; wenn alle Koeffizienten
betragsmässig < 1 sind, dann ist das Filter garantiert stabil. Dass ein
Lattice-Filter prinzipiell einen höheren Rechenaufwand hat, als ein
"konventionelles" wird kompensiert durch die Tatsache, dass man mit IIR
mit weniger Taps schon dieselbe Flankensteilheit erreichen kann, wie bei
FIR.
Die Rechenleistung eines STM32 oder von irgendwas anderem kann man sehr
gut abschätzen. Einheit ist MMAC/s ( million multiply/acumulate per
second ). Der STM32F4... läuft z.B. maximal mit ca. 160MHz und benötigt
3Takte für float (32Bit) multiply/accumulate ( AN 4044 von ST). Dann hat
der eine 32Bit floatig Leistung von ca 53 MMAC/s brutto.
Jetzt die Anforderung: 2Kanäle, 24Bit, 96kHz, 512taps:
2Kanäle 96kHZ 512taps = 98.3 MMAC/s. Da ist der STM32F4 mehr als
Faktor 2 zu lahm, allerdings in float.
AFAIK schafft der aber 32x32 Bit integer MAC in einem cycle, damit würde
das dann gehen. Ist aber auf Kante genäht.
Cheers
Detlef
Tobias P. schrieb:> Ich würds, da es 24 Bit sein sollen, mit der FPU machen.
Die Genauigkeit der Single-Precision-FPU ist aber nur 23 Bit, d.h.
alleine schon beim Konvertieren geht 1 Bit verloren, oder seh ich das
falsch?
Detlef _. schrieb:> 2Kanäle 96kHZ 512taps = 98.3 MMAC/s. Da ist der STM32F4 mehr als> Faktor 2 zu lahm, allerdings in float.
Er sprach von einem Kanal, trotzdem noch zu wenig.
Detlef _. schrieb:> AFAIK schafft der aber 32x32 Bit integer MAC in einem cycle, damit würde> das dann gehen. Ist aber auf Kante genäht.
Bei 512 Taps reicht das nie und nimmer bei der Auflösung. Bin auch an
ähnlichen Dingen dran. Dann ist es so, dass das Prozzilein ja auch noch
anderes zu tun bekommt.
Der übliche Weg ist daher das Signal per FFT in die frequency domain zu
transformieren. Dort ist FIR wesentlich weniger rechenintensiv. Danach
dann IFFT und fertsch. Google mal "overlap add"
Gibt auch irgendwo Formeln, die den Rechenaufwand der direkten
Implementierung mit den Verfahren in der frequency domain vergleichen,
und da sieht man, dass es schon nach relativ wenigen Taps (30? nagel
mich nicht fest) etwa quadratisch auseinanderläuft und sich somit der
zusätzliche Aufwand für FFT und IFFT relativ schnell bezahlt macht.
Edi M. schrieb:> Ähem: Eine FFT IST ein FIR und zwar ein mehrfach paralleler. Wenn Ich> einen einzigen Filter benutzen möchte, brauche Ich keine komplette FFT.
Öhm, ein FIR ist ein Filter, der (je nach Koeffizienten) auf alle
Frequenzen wirken kann.
FFT zerlegt das Signal erstmal nur in Frequenz-Bänder. Um einen Filter
daraus zu machen, muss man danach erstmal die Frequenzbänder mit dem
Filter multiplizieren und dann das Signal per IFFT wieder in die time
domain bringen.
Oder was meinst du mit "einen einzigen Filter benutzen"?
Moin,
Joe F. schrieb:> -> letzte Seite.> Bei 64 Taps kreuzen sich die Wege.
Das seh' ich zwar auch, alleine da fehlt mir die Vorstellungskraft.
Auf der einen Seite hab' ich ein klassisches FIR mit N Taps. Macht also
pro Tap eine MAC-Operation, d.h. eine Multiplikation 2er reeller Zahlen
und eine Addition. Dann vielleicht noch bisschen
Pointerarithmetik/Speicherschieberei. Und fertsch. Ich wuerde mal fuer
den M4 so groessenordnungsmaessig ausm Bauch raus vielleicht so mit 5
Takten/Tap rechnen. Aber eben nur so ausm Bauch raus.
So, und jetzt will mir wer erzaehlen, dass wenn ich eine FFT mach,
danach jedes Ausgangsdatum dieser FFT mittels einer komplexen
Multiplikation (= 4 reelle Multiplikationen + 2 reelle Additionen) dann
mit den (vorher einmalig transformierten) Filterkoeffizienten verwurste
und dann den ganzen Schlonz wieder zurueck-IFFTe, dass das dann ab
40..80 Taps schneller gehen soll? Hmmmmmmmm....Naja...Also...Neee, da
fehlt mir immernoch die Vorstellungskraft, wie das gehen soll.
Gruss
WK
Das ist genau das, was Ich meine. Beim FIR-Filter, auch bei einem
komplexen Filter rechne Ich exakt dasselbe, wie bei der FFT. Die FFT
faltet ja doch die eingehenden Daten mit eben einem Sinus / Cosinus und
damit jeweils den individuellen Koeffizienten.
Sicher, bei der FFT kann man Vieles kombinieren und es fällt viel weg,
aber das kann hinten und vorne nicht sein.
Dergute W. schrieb:> Neee, da> fehlt mir immernoch die Vorstellungskraft, wie das gehen soll.
Bei der direkten Implementierung muss du ja jedes Sample mit jedem
Koeffizienten multiplizieren (Aufwand = Taps^2).
Also steigt der Aufwand quadratisch zur Anzahl der Taps.
Beim "Umweg" über die frequency domain arbeitest du Blockweise.
D.h. du hast zwar einen Overhead, um einen Block Samples in Frequenzen
zu zerlegen, dafür muss man pro Tap dann nur noch ein mal
multiplizieren.
Aufwand = FFT + Taps + IFFT.
D.h. es gibt einen Grundaufwand für die FFT und IFFT des Sample-Blocks,
der aber schnell (im oben verlinkten Paper ab 64 Taps) dadurch wieder
wett gemacht wird, dass der Aufwand für das Multiplizieren mit den
Koeffizienten linear mit der Anzahl der Koeffizienten steigt (im
Gegensatz zu direkten Implementierung: kein Grundaufwand dafür n^2
Multiplikationen für die Taps).
Bei sagen wir mal 1024 Taps macht sich das dann schon sehr, sehr
deutlich bemerkbar (eben ca. Faktor 1024, da FFT und IFFT im Verhältnis
zu den 1048576 Multiplikationen bei direkter Implementierung
vernachlässigbar sind).
Hi,
hat der F7 nicht immer schon einen DSP mit an Board ? Ist doch die
Cortex M7 Variante von STM oder nicht ? Ich dachte immer die hätten DSP
standardmäßig mit an Board...
Hatte sowas vor langer Zeit mit einem externen DSP gemacht und muss
sagen, dass es Dinge gab, die nachher mehr Probleme gemacht haben, als
die FIR Filter. Bei mir war die Varianz und der indizierte Jitter ein
Problem. Das würde wieder für einen FPGA mit einem guten FlipFlop und
externem Quarz zum takten sprechen. Um die Varianz zu eliminieren wirst
du nicht um einen Puffer drumherum kommen. Vll geht das auch auf nem F7
fix genug, weiss nicht genau. Es wäre nett, wenn du mal schreiben
würdest, wie gut das bei dir geklappt hat.
Kleinere Filter kann man heutzutage auch mit manchen DAC Chips
erledigen. Der TI PCM5142 z.B. hat schon einen kleinen DSP mit an Board.
Viel Glück, bin mal gespannt wie du das Problem angehst.
Moin,
Mir schwant so langsam, was die Paperverfasser da meinen koennten. Der
Gesamtaufwand fuer eine Faltung eines bestimmten Signals mit einer
bestimmten Laenge mit einem bestimmten Satz Filterkoeffizienten - da
kanns schon sein, dass da was quadratisch ansteigt.
Aber: Entscheidend fuer den TE ist ja nicht die Gesamtanzahl
Rechenoperationen, um z.b. ein Musikstueck zu filtern, sondern die
Anzahl Rechenoperationen pro Eingangssample. Das steigt linear mit den
Taps an.
Bei den Filtern mit Riesen-FFT hin und zurueck wirds auch mit der
Totzeit (und damit auf µControllern dem RAM-Bedarf) etwas unangenehm. Da
ist das Musikstueck schon durchgedudelt, dann kanns erst geFFT werden,
dann hurtig die Multiplikationen und die IFFTierung. Erscheint mir nicht
praktikabel.
Gruss
WK
Tja, beim nochmaligen drüberschauen ist mir tatsächlich auch nicht
wirklich klar, wie die auf einen quadratischen Anstieg bei der direkten
Form kommen.
Denn du hast recht, die Anzahl der Multiplikationen nimmt eigentlich
linear mit der Anzahl der Taps zu.
Bei der FFT Methode ist es eher eine log() Funktion.
Hier ist das auch nochmal etwas besser erklärt:
http://acoustics.aau.dk/~sko/3d/slides/5.pdfDergute W. schrieb:> Da> ist das Musikstueck schon durchgedudelt, dann kanns erst geFFT werden,> dann hurtig die Multiplikationen und die IFFTierung. Erscheint mir nicht> praktikabel.
Das mit dem Delay ist richtig, auf wenn von dir stark übertrieben ;-)
Ein Filter mit 512 Taps erzeugt bei der FFT Methode und bei 48 KHz ein
Delay von 10ms. Ist meistens durchaus akzeptabel.
Um das Delay zu verkürzen (vor allem bei längeren Filtern), zerlegt man
den Filter eben in kleinere Portionen und wendet das overlap-add
Verfahren an.
Klar, da ist etwas mehr Speicher nötig. Man muss halt individuell
entscheiden was der richtige Weg ist.
WS schrieb:> Joe F. schrieb:>> Ein Filter mit 512 Taps erzeugt bei der FFT Methode und bei 48 KHz ein>> Delay von 10ms.>> Wie rechnet sich das denn, bitte?
Ergibt sich einfach aus der notwendigen Blockgröße von 512 Samples ->
512/48000 = 0.011 s
Kommt jetzt natürlich drauf an, wie schnell der Prozessor ist um FFT und
IFFT zu machen. Auf einem uC würde man dann nochmal die gleiche Zeit
einplanen, und das gemütlich abfrühstücken während der nächste
Sampleblock reinläuft.
Moin,
Die 10 msec wegen 512/48kHz kauf ich fuer ein "normales" FIR ab. Fuer
das FFT/IFFT Dingens gehts allerschnellstens in der doppelten Zeit. Und
das auch nur, wenn die (I)FFT und die ganzen komplexen Multiplikationen
exakt in 0 Takten/sec ablaufen. Sonst dauert's eben noch laenger...
Gruss
WK
Nein. Die normale FIR hat keine Verzögerung, da immer in die
Vergangenheit gerechnet wird.
FFT sieht so aus:
1
0ms 11ms 22ms
2
3
+---------------------+
4
| 512 Samples buffern |
5
+---------------------+
6
| +---------------------+
7
+->| FFT / Multipl./IFFT |
8
+---------------------+
9
| +---------------------+
10
+->| Samples ausgeben |
11
+---------------------+
12
13
+---------------------+
14
| 512 Samples buffern |
15
+---------------------+
16
| +---------------------+
17
+->| FFT / Multipl./IFFT |
18
+---------------------+
19
| +---------------------+
20
+->| Samples ausgeben |
21
+---------------------+
Wenn du der FFT, den Multiplikationen und der IFFT genauso viel Zeit
einräumst, wie ein Buffer reinläuft, brauchst du exakt 2x soviel Zeit,
bis die ersten Samples wieder raus gehen.
Die Berechnung des Filters und das Buffer-handling müssen entsprechend
parallel ablaufen - in der Regel kein Problem, da Buffer füllen und
leeren kein großer Rechenaufwand ist.
Joe F. schrieb:> Nein. Die normale FIR hat keine Verzögerung, da immer in die> Vergangenheit gerechnet wird.
Aber genau deshalb hat die Berechnung doch eine Verzögerung: Sowohl bei
einem FIR, als auch der FFT und jedem anderen ähnlich gestrickten
Filter, bei dem "in die Vergangenheit geschaut wird".
> FFT sieht so aus:
Beim FIR sieht es auch so aus, wobei BEIDE auch on-the-fly arbeiten
können, speziell die FFT dies aber nicht tut und zwar im Wesentlichen
aus Effizienzgründen. Letztlich ist die FFT in der Tat nichts anderes,
als mehrfach parallelisierte FIR-Filterung mit jeweils den einzelnen
Frequenzen.
Zu Deiner Grafik:
FFTs, die fortgesetzt prozessieren sollen, können nicht nur immer Blöcke
dieser Art herausschneiden, sondern müssen übelappen, aber das steht
noch auch einem anderen Blatt. Allerdings kann man dann (und nur dann!)
die Auflösung der FFT mit der des FIR vergleichen, weil der nämlich
i.d.R. so aufgestellt ist. Das ist auch das, was WeKa mit dazu bewogen
hat, spontan die These infrage zustellen, ob man da mit der FFt besser
fährt.
Das ist nämlich SO nicht der Fall!
Das ist auch deshalb nicht der Fall, weil man die FFT über mehr, als
eine Periode erstrecken muss, um einen kontinuierlichen Datenstrom
weitgehend verzerrungsfrei sampeln und resynthetisieren zu können,
ansonsten wirkt nämlich das Fenster und dies ist mit FIR weniger
kritisch und auch einfacher realisierbar.
Ich habe genau diese Geschichte bei Raumimpulsantworten für
Echogeneration und -elimination bis aufs Bit durchexerziert - es gibt da
immer massive Artefakte bei FFT<->IFFT, die die Methode für z.B. Audio,
wo man kleinste Probleme direkt hören kann, disqualifizieren oder
zumindest stark einschränken.
Jürgen S. schrieb:> Joe F. schrieb:>> Nein. Die normale FIR hat keine Verzögerung, da immer in die>> Vergangenheit gerechnet wird.> Aber genau deshalb hat die Berechnung doch eine Verzögerung: Sowohl bei> einem FIR, als auch der FFT und jedem anderen ähnlich gestrickten> Filter, bei dem "in die Vergangenheit geschaut wird".
Klar, der Filter an sich verursacht eine gewisse Verzögerung (Phase),
das kann man ja nicht ändern.
Allerdings kommt bei der direkten Implementierung eben schon ab Sample 0
am Eingang schon ein Sample am Ausgang heraus. Ganz am Anfang
funktioniert der Filter natürlich nicht richtig, da ja keine bzw. zu
wenig "Historie" da ist.
Bei der blockweisen Verarbeitung kommt aber noch die Zeit dazu, die
benötigt wird um einen Buffer zu füllen, damit man überhaupt eine FFT
machen kann.
Es gibt Verfahren, die beides kombinieren, kleinere erste Portion mit
direkter Implementierung, und danach mit FFT. Dadurch kann man dann auch
wieder auf Real-Time kommen. Ist aber halt sehr aufwändig.
Jürgen S. schrieb:> Zu Deiner Grafik:>> FFTs, die fortgesetzt prozessieren sollen, können nicht nur immer Blöcke> dieser Art herausschneiden, sondern müssen übelappen, aber das steht> noch auch einem anderen Blatt
Das ist richtig. Ich habe mir das der Einfachheit halber geschenkt.
Trägt ja nichts zum Thema "Delay" bei.
Jürgen S. schrieb:> Ich habe genau diese Geschichte bei Raumimpulsantworten für> Echogeneration und -elimination bis aufs Bit durchexerziert - es gibt da> immer massive Artefakte bei FFT<->IFFT, die die Methode für z.B. Audio,> wo man kleinste Probleme direkt hören kann, disqualifizieren oder> zumindest stark einschränken.
Das kann ich nicht bestätigen. Ich habe vor einiger Zeit 32 FIRs mit 512
Taps auf einem System ohne FPU implementiert, das arbeitet mit 32 bit
Integer. Trotz Umweg über FFT und IFFT, overlap add ist die 24-Bit Audio
Performance einwandfrei.
Direkte Implementierung habe ich am Anfang auch ausprobiert, dann aber
aus Performancegründen aufgeben müssen.
Ich krame das gerne nochmal raus, um genauere Werte zu nehmen. Eure
Argumentation hat durchaus überzeugende Aspekte ;-)
Aus dem Kopf heraus bekomme ich es gerade nicht mehr zusammen, warum die
beiden Verfahren einen so großen Unterschied bezügl. Performance machen.
