» Veranstaltungen
» Navigation
» über uns
|
» Registrierung
Liebe Mitleserinnen, Mitleser, Foristinnen und Foristen,
wer sich von Euch in letzter Zeit mit dem Gedanken getragen hat, Mitglied unseres wunderbaren IGDH-Forums zu werden und die vorher an dieser Stelle beschriebene Prozedur dafür auf sich genommen hat, musste oftmals enttäuscht feststellen, dass von unserer Seite keine angemessene Reaktion erfolgte.
Dafür entschuldige ich mich im Namen des Vereins!
Es gibt massive technische Probleme mit der veralteten und mittlerweile sehr wackeligen Foren-Software und die Freischaltung neuer User ist deshalb momentan nicht mit angemessenem administrativem Aufwand möglich.
Wir arbeiten mit Hochdruck daran, das Forum neu aufzusetzen und es sieht alles sehr vielversprechend aus.
Sobald es dies bezüglich Neuigkeiten, respektive einen Zeitplan gibt, lasse ich es Euch hier wissen.
Das wird auch für alle hier schon registrierten User wichtig sein, weil wir dann mit Euch den Umzug auf das neue Forum abstimmen werden.
Wir freuen uns sehr, wenn sich die geneigten Mitleserinnen und Mitleser, die sich bisher vergeblich um eine Freischaltung bemüht haben, nach der Neuaufsetzung abermals ein Herz fassen wollen und wir sie dann im neuen Forum willkommen heißen können.
Herzliche Grüße von Eurem ersten Vorsitzenden der IGDH
Rainer Feile
-
Erfahrener Benutzer
Servus
Ich hab den Post nun gefunden, da wird es erklärt!
http://www.diy-hifi-forum.eu/forum/s...8&postcount=44
Ich hoffe, ich konnte zur allgemeinen Verwirrung beitragen
-
Entspricht ja dem was ich geschrieben habe.
Zwei Anmerkungen:
Je kleiner das Päckchen, desto größer die Prozessorbelastung.
Das darf man nicht als proportionalen Zusammenhang verstehen. In der Praxis bekommt man unterhalb einer - von der Architektur abhängigen - Blockgröße eine ganze Menge Bonus. Der Grund sind die bei großen FFT-Längen notwendigen Speicherzugriffe auf höhere Cacheebenen bzw. - am schlimmsten - den Hauptspeicher. Kleine FFTs können vollständig im Cache ablaufen, und müssen nur auf andere Speicherbereiche zugreifen um den nächsten Bock zu laden; in der Summe sind das viel weniger dieser äußerst langsamen Operationen.
Was die ausmachen mal ein Beispiel: als ich mich vor einigen Jahren mal damit näher beschäftigt habe schrieb ich meine eigene FFT (Rechenzeit sehr eng mit dem bekannten O(n*log(n)) skalierend) etwas um. Ich sortierte ein wenig die Schleifen und Rechenoperationen um, so dass letztere auf möglichst nah beieinander liegende Speicherbereiche arbeiteten. Unterhalb einer bestimmten FFT-Größe (ich meine es waren 65k bei 64-Bit breiten reellen Zahlen) war die neue FFT fast um den Faktor 3 schneller als die alte. Darüber dann allerdings deutlich langsamer, was ich mir nie erklären konnte
Außerdem können viele kleine FFTs leichter auf Multicore umgesetzt werden. Ob das einen Geschwindigkeitsvorteil bringt weiß ich nicht (denn jede FFT kann mit Multicore arbeiten).
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)
Ich glaube da fehlt ein Wort. Es müsste non-uniform partitioned convolution heißen.
-
Zitat von Murphy
Oh ja, das hat sehr zur Aufklärung beigetragen, insbesondere der Tabelle vom UE5. Somit sind die bins die Pakete, die Bodzio in seine FFT-convolution reinsteckt. Trotzdem scheint er bei längeren Paketen automatisch seine Taps zu erhöhen, wir kennen nur noch nicht die Korrelation. JohnK redet hier
http://www.diyaudio.com/forums/multi...ml#post3298968
von 8192 taps, aber er sagt nicht, bei welcher Puffergröße (bzw. die war vielleicht in der v2/v3 noch fest).
Rätselhaft wird es, was die tatsächliche Latenz von Acourate angeht. Der von Dir angegebene Post von Uli sagt sehr deutlich, daß
a) eine minimalphasiges FIR bei direkter convolution 0 delay hat, da die größten Koeffizienten vorne stehen, und ein praktischer Delay im vielleicht knapp zweistelligen ms-Bereich durch die partition FFT convolution dazukommt.
b) ein linearphasiges FIR ein minimales Delay von der halben Filterlänge hat, da die Koeffizienten symmetrisch und das Maximum in der Mitte ist. Dazu kommen noch die Delays von der convolution engine.
Ein linearphasiges FIR mit 64K Koeffizienten hat somit bei 44 oder 48 kHz zwangläufig mindestens 0,7 s Latenz, aber was kommen praktisch noch für Delays durch convolution und Anbindung der Soundkarte dazu? Die von Murphy genannten über 2 s scheinen mir arg viel, aber einen ähnlichen Wert habe ich heute schon irgenwo anders im Netz für Acourate gefunden.
Die andere Frage ist die, ob die 0,7 Hz Auflösung eines 64K Filters überhaupt ausgenutzt werden.
JohnK führt hier auf, daß Ultimate Equalizer bei 8K Filter theoretisch 5,8 Hz Auflösung hätte, sich aber zusätzliche Fehler bei der Filterberechnung aufgrund des windowing des Meßimpulses einschleichen würden, die dann doch wieder ein iteratives manuelles Optimieren durch Anschauen des realen Ergebnisses und Ändern der Vorgabewerte erfordert:
http://www.diyaudio.com/forums/multi...ml#post3300656
Wie ist das in Acourate gelöst? Ist der Meßimpuls lang genug zur Ausnutzung der Frequenzauflösung bzw. kann er das in Innenräumen überhaupt sein? Oder ist die iterative Optimierung automatisiert?
-
Erfahrener Benutzer
-
Zitat von Murphy
0,68*3=2,04s
Ich schließe daraus, dass es kein partitioned convolving ist, aber linker und rechter Kanal parallel gefaltet werden. Denn sonst wären es vier Sekunden.
Das verstehe ich nicht. Wieso *3? Die Kanäle werden parallel verarbeitet. Die Latenz sollte sein
0,68 s + Latenz des Convolvers + Latenz der Audioausgabe
Was die 8192 Taps (5,8 Hz Auflösung) angeht, in dem Thread mit den Zitaten von JohnK wird gezeigt, das die durchaus ausreichen, um ein analoges Filter 2. und 3. Ordnung bei 20 Hz sauber nachzubilden. Das Problem ist halt, daß UE anscheinend die notwendigen Koeffizienten wegen der Fensterung nicht genau genug berechnet.
Wie faltest Du eigentlich? VST aus Acourate? BruteFIR? AcourateASIO?
Was neuen Thread angeht, dann könnte ein lieber Moderator fast alles ab Post 298 oder so in einen neuen packen, leider ist zwischendurch immer wieder etwas Dirac mit drin.
-
Erfahrener Benutzer
Das verstehe ich nicht. Wieso *3? Die Kanäle werden parallel verarbeitet. Die Latenz sollte sein
0,68 s + Latenz des Convolvers + Latenz der Audioausgabe
Also, ich habe einen 3-Weger, den ich mit Acourate (+ Acourate Convolver) aktiv ansteuere. Ich habe also 6 Ausgangskanäle. Daher mal 3, in diesem Fall.
Was die 8192 Taps (5,8 Hz Auflösung) angeht, in dem Thread mit den Zitaten von JohnK wird gezeigt, das die durchaus ausreichen, um ein analoges Filter 2. und 3. Ordnung bei 20 Hz sauber nachzubilden. Das Problem ist halt, daß UE anscheinend die notwendigen Koeffizienten wegen der Fensterung nicht genau genug berechnet.
Sorry, die ich habe nicht alle gelesen, ich bin aktuell etwas im Stress. Ich glaube dir gern, dass das mit 8k Tabs auch noch geht. Leider hätte ich in diesem Fall in meinem Setup noch immer ~250ms.
-
Nee, die 3 (eigentlich ja 2x3 = 6) Kanäle werden alle parallel gefaltet und über DMA oder sowas an die Soundkarte übertragen. Anders wäre es nur, wenn die Power der CPU nicht ausreichen würde. Dann würde die größere Latenz aber auch keine Entlastung bringen, sondern nur ein 3x verringertes Abspieltempo, bzw. da das nicht geht, würde es zu Aussetzern kommen.
-
Erfahrener Benutzer
Ich kann mit Fug und Recht behaupten: Ich bin überfragt!
-
Zitat von capslock
Ein linearphasiges FIR mit 64K Koeffizienten hat somit bei 44 oder 48 kHz zwangläufig mindestens 0,7 s Latenz, aber was kommen praktisch noch für Delays durch convolution und Anbindung der Soundkarte dazu?
Nicht viel. Linuxens ALSA hat eine sehr geringe Latenz, mit ASIO ist auch nahezu Realtime möglich. Insgesamt wenige Millisekunden.
JohnK führt hier auf, daß Ultimate Equalizer bei 8K Filter theoretisch 5,8 Hz Auflösung hätte, sich aber zusätzliche Fehler bei der Filterberechnung aufgrund des windowing des Meßimpulses einschleichen würden, die dann doch wieder ein iteratives manuelles Optimieren durch Anschauen des realen Ergebnisses und Ändern der Vorgabewerte erfordert:
Ja, das ist richtig. Die Fehler durch die Fensterung sind allerdings umso höher, je kürzer das Filter ist. Grund ist die Kompaktheit der Impulsantwort, d. h. an den Rändern befindet sich weniger "Information". Genau diese Ränder werden durch die Fensterung beeinflusst.
Die richtige Erzeugung eines FIRs ist nicht ganz trivial, aber auch kein rocket science. Es gibt auch unterschiedlichste Ansätze wie man das angeht. Letztlich gibt es bei der Erzeugung von Raumentzerrungsfiltern einen entscheidenden Schritt der das Ergebnis massiv beeinflusst und für die Unterschiede zwischen verschiedenen FIR-Entzerrern verantwortlich ist: das Vorbereiten/Analysieren des gemessenen Frequenzgangs. Alles andere ist notwendige Mathematik, aber in diesem Punkt gibt es halt Abweichungen. DRC-FIR macht da was komplexes mit variablem Gating, ich selber benutze auf der Arbeit einen Wavelet-Ansatz (streng genommen sind die beiden gar nicht so weit auseinander). Was UE oder Acourate da machen weiß ich nicht.
Edit: die 6 Kanäle werden selbstverfreilich parallel berechnet und haben alle die gleiche Verzögerung und addiert sich nicht auf
-
Chef Benutzer
Ähnliche Themen
-
Von Herr_Mo im Forum Messen und Simulieren
Antworten: 9
Letzter Beitrag: 05.07.2012, 15:57
-
Von adrian im Forum neue Mitglieder
Antworten: 0
Letzter Beitrag: 11.11.2011, 12:42
-
Von *-JP-* im Forum Allgemeine Themen
Antworten: 18
Letzter Beitrag: 29.01.2011, 19:47
-
Von Woofy im Forum neue Mitglieder
Antworten: 1
Letzter Beitrag: 12.01.2011, 00:01
Forumregeln
- Es ist dir nicht erlaubt, neue Themen zu verfassen.
- Es ist dir nicht erlaubt, auf Beiträge zu antworten.
- Es ist dir nicht erlaubt, Anhänge hochzuladen.
- Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.
-
Foren-Regeln
|