Dirac Live Active Room Treatment & Passendes Equipment und mögliche Kombinationen

Hier Infos zu PRT:

BjoernMZ (Beitrag #3446) schrieb:

Doch, gerade da gehen die DSPs alle in die Knie. Ich schätze mal so über den Daumen, unter 5000 Tabs, ist im Bass Bereich nichts machbar mit FIR und DSP... Der Storm hat fast 4000Tabs, aber für alle Kanäle...ich fahr zb auf dem PC mir i5 ca 200000Tabs pro Kanal, ist allerdings auch Frequenzweiche und Raumkorrektur in einem... Ich habe mal versucht alles über FIR mit dem Najda DSP zu fahren. Der war völlig überfordert... Beim Trinnov macht der PC aber auch nur das Filterdesign... Glaub ich...Convolver dann über den DSP

Die Frage, die sich mir hier stellt. DIRAC erledigt die Berechnung ja passiv und überträgt die Kurven erst dann. Hast Du Dein System vielleicht in Echtzeit laufen? Dann kann ich mir durchaus vorstellen, dass permanente Neuberechnungen gar in Echtzeit ein System überfrachten und somit überlasten kann.
Das ist ein eklatanter Unterschied....

Möglicherweise ist ja bei Trinnov die DIRAC Software includiert, so dass die einen eigenen Weg gehen, also die Messprozedur dort im Receiver selber stattfindet. Das würde zumindest die Intel CPU erklären.....

Trinnov hat sein eigenes System.
Am Ende sind es aber immer fir Filter die zur Laufzeit angewendet werden müssen, genau diese Leistung müssen die DSPs (nicht bei Trinn8v) erbringen.

Da D&M ja sogar in den unteren Ebenen ART implementieren möchte, scheint es hier aber wohl keine solche Bedenken zu geben. Möglicherweise wird man die Filteranzahl halt begrenzen (und da wäre dann Trinnov sicherlich im Vorteil (aber auch teurer n ganzes Stück).

Klar wird es irgendwie gehen, nur wie gut Im Vergleich zu dem was möglich ist (bei ausreichend Leistung).

Um die Filteranzahl geht es ja, was ist nötig, was kann der DSP pro Kanal leisten und bei welcher Samplingfrequenz.

Hier schweigen sich alle Beteiligten aus, weder von den AV Herstellern noch von den Entwicklern der Einmesssysteme kommt da irgendwas.
Klar, man will ja sein Zeug verkaufen.

Scurl (Beitrag #3458) schrieb:

Die Frage, die sich mir hier stellt. DIRAC erledigt die Berechnung ja passiv und überträgt die Kurven erst dann.

Es werden keine Kurven übertragen. Dirac bastelt Filter und überträgt die zum AVR.

Hast Du Dein System vielleicht in Echtzeit laufen? Dann kann ich mir durchaus vorstellen, dass permanente Neuberechnungen gar in Echtzeit ein System überfrachten und somit überlasten kann.

Das einzige, was im AVR in Echtzeit läuft, sind die DSPs mit ihren Filtern, Signal-Routing, DAC, etc. . Da wird nichts neu gemessen und neu berechnet. Messen und Berechnen erfolgt einmalig. Danach ist das alles fix im AVR.

DIRAC nennt das Ganze "Zielkurven" die man bearbeitet und exportiert "Filter", ja die meine ich.

Zum Rest. Du kennst BjörnMZ System? Ich bin von seinem System nicht von einem AC-Receiver ausgegangen...

Scurl (Beitrag #3463) schrieb:

Du kennst BjörnMZ System?

Acourate? Interessiert hier nicht die Bohne. Das hier ist ein DLART-Thread.
Acourate macht auch nichts anderes: Filter erstellen.

Um die Filteranzahl geht es ja, was ist nötig, was kann der DSP pro Kanal leisten und bei welcher Samplingfrequenz. Hier schweigen sich alle Beteiligten aus, weder von den AV Herstellern noch von den Entwicklern der Einmesssysteme kommt da irgendwas.

In einem minidsp DDRC-24 steckt folgendes: hier.
Digital Signal Processor Engine: Analog Devices Floating point DSP SHARC ADSP21489
Internal Processing resolution & Sample rate: 32 bit / 48kHz
Input/Ouput Configuration: 2 in / 4 out

Es wurde auch mehrmals behauptet das in einem DSP nichts berechnet werden würde. Wenn die Filter einmal "drin" sind,
kämen sie nur noch zur Anwendung.

Wenn dem so gemein ist, dann ist das falsch. Jedes Filter wird in einem DSP, wenn es zur Anwendung kommt, mit den Audiodaten
versorgt und muss die Koeffizienten berechnen. Nicht umsonst hat diese DSP auch Hardware Eccelerator für FIR-Filter.

Das Filterdesign selbst wird auch nicht unbedingt von DIRAC aufgrund der Messungen erstellt. Diese werden von einer Datenbank
gezogen. Ein PC, oder auch MAC, wäre schlicht zu langsam um alle Filter in einem erträglichen Zeitraum zu berechnen. Die Mathematik für ein FIR-Filterdesign ist nun jetzt keine Raketentechnik, dafür aber sehr komplex. Hinzu kommt, das unterschiedliche Filter kombiniert werden um bestmögliche Ergebnisse zu erzielen.

AusdemOff (Beitrag #3465) schrieb:

Es wurde auch mehrmals behauptet das in einem DSP nichts berechnet werden würde. Wenn die Filter einmal "drin" sind, kämen sie nur noch zur Anwendung.

Dabei war das Verabeiten von Meßdaten und Erstellen der Filter gemeint, nicht das Anwenden der Filter.

Jedes Filter wird in einem DSP, wenn es zur Anwendung kommt, mit den Audiodaten versorgt und muss die Koeffizienten berechnen.

So richtig wissen tust Du's aber auch nicht: das Filter berechnet doch keine Koeffizienten. Es enthält die Koeffizienten, die die Messoftware / die Filtererstellung berechnet hat.
Ein Filter besteht aus einer Funktion mit Platzhaltern für Koeffizienten, für die die Filtererstellung konkrete, konstante Werte ermittelt hat.

Nur zu dumm das digitales Filterdesign eines meiner Schwerpunkte im Studium war.

An dieser Stelle empfehle ich dir die Grundlagen der Systemtheorie und ihre Anwendung, sprich, wie digitale Filter
funktionieren. Und zwar eben in der digitalen Ebene und nicht als Analogon.

Ein Filter besteht aus einer Funktion mit Platzhaltern für Koeffizienten, für die die Filtererstellung konkrete, konstante Werte ermittelt hat.

Lass' mich nett zu dir sein, und zwar mit deinen eigen Worten: So richtig wissen tust Du's aber auch nicht.
Anders ist dein obiges Statement nicht zu erklären.

BassTrap (Beitrag #3464) schrieb:

Scurl (Beitrag #3463) schrieb: Du kennst BjörnMZ System? Acourate? Interessiert hier nicht die Bohne. Das hier ist ein DLART-Thread. Acourate macht auch nichts anderes: Filter erstellen.

Kann es sein, dass Du a) weder meine Anfrage an den Poster verstanden hast und b) nicht wirklich weisst, dass hier offenbar einige Dinge vermischt werden?

Ein Einmesssystem ohne Zubehör ist wenig praxisorientiert. Daher sollte man schon wissen, ob die SW IM Gerät existiert oder nicht, also ob Messungen IM Gerät vorgenommen werden oder durch Aussen seitens externer Hardware. Den Rest kann man sich dann nämlich sparen, wenn Poster A zum Thema X schreibt und Poster B zum Thema Y, sich zwar beide auf das Thema Z beziehen, aber die Vorraussetzungen vollkommen anders gegeben sind.

WIE WAS WO abgespeichert wird, werden wohl nur die SW / FW und HW-Hersteller wissen!

AusdemOff (Beitrag #3467) schrieb:

Ein Filter besteht aus einer Funktion mit Platzhaltern für Koeffizienten, für die die Filtererstellung konkrete, konstante Werte ermittelt hat. Lass' mich nett zu dir sein, und zwar mit deinen eigen Worten: So richtig wissen tust Du's aber auch nicht. Anders ist dein obiges Statement nicht zu erklären.

Filterkoeffizienten werden bei FIR- und IIR-Filter vor ihrem Einsatz ermittelt und sind dann fix. Bei adaptiven Filtern (lernfähige Systeme) ändern sie sich während des Einsatzes. Dirac ist aber nicht lernfähig, ermittelt die Filterkoeffizienten aus den Meßdaten.

Scurl (Beitrag #3468) schrieb:

Ein Einmesssystem ohne Zubehör ist wenig praxisorientiert. Daher sollte man schon wissen, ob die SW IM Gerät existiert oder nicht, also ob Messungen IM Gerät vorgenommen werden oder durch Aussen seitens externer Hardware.

Du schriebst von permanenter Neuberechnung in Echzeit. Damit kannst Du ja nur das Neuerstellen der Filter meinen, denn in Echtzeit errechnen alle Filter aus dem Eingangssignal das korrigierte Ausgangssignal, was nicht sonderlich erwähnenswert ist, da es ja bei jeder Filteranwendung stattfindet.
Wie soll denn BjoernMZs System permanente Neuberechnungen in Echzeit durchführen? Dazu braucht es wohldefinierte Meßsignale.

Ich hatte ja geschrieben das die Latenz in der Anwendung der Filter wesentlich länger dauert als die Filter aus der Messung berechnet wurden..20sek buffern vor dem ersten Ton am LS...Ob Dirac oder Acourate die FIR Filter erstellt macht da vermutlich keinen Unterschied..Ich kann mein System wenigstens schon benutzen....
Raumkorrektur in Echtzeit ist auch quatsch, der Raum verändert sich ja eher selten beim Hören..

BassTrap (Beitrag #3470) schrieb:

Scurl (Beitrag #3468) schrieb: Ein Einmesssystem ohne Zubehör ist wenig praxisorientiert. Daher sollte man schon wissen, ob die SW IM Gerät existiert oder nicht, also ob Messungen IM Gerät vorgenommen werden oder durch Aussen seitens externer Hardware. Du schriebst von permanenter Neuberechnung in Echzeit. Damit kannst Du ja nur das Neuerstellen der Filter meinen, denn in Echtzeit errechnen alle Filter aus dem Eingangssignal das korrigierte Ausgangssignal, was nicht sonderlich erwähnenswert ist, da es ja bei jeder Filteranwendung stattfindet. Wie soll denn BjoernMZs System permanente Neuberechnungen in Echzeit durchführen? Dazu braucht es wohldefinierte Meßsignale.

Es wäre nett, wenn Du nicht nur querlesen würdest.
Da ich nicht weiss, was ein User a) hat und b) meint, frage ich im Normalfall nach um zu verstehen, was er meint und was er hat.
Ich stelle mir aus IT-Sicht die Frage, was hier eine 100% CPU Zeit veranschlagen sollte und warum hier Speicher nicht ausreichen sollte....um das zu verstehen, benötigt man ja zumindest erstmal Wissen um das Gesamtsystem? ICH stelle mir maximal vor, wenn Dinge in Echtzeit berechnet werden, dass diese vielleicht so eine Last verursachen. Ich schreibe nicht, dass dieses der Fall ist. Verstanden?

@BjoernMZ
Danke für die Info.

Scurl (Beitrag #3472) schrieb:

Es wäre nett, wenn Du nicht nur querlesen würdest. ;)

Wieso querlesen?
In #3458 hast Du Dir eine Frage gestellt, die mich darauf schließen läßt, daß Du eine sehr phantasiereiche Vorstellung davon hast, was in Raumkorrektursystemen vor sich geht.
Du schreibst zum einen: "DIRAC erledigt die Berechnung ja passiv und überträgt die Kurven erst dann."
Direkt im Anschluß stellst Du eine These auf mit: "Hast Du Dein System vielleicht in Echtzeit laufen? Dann kann ich mir durchaus vorstellen, dass permanente Neuberechnungen gar in Echtzeit ein System überfrachten und somit überlasten kann."
Das bedeutet doch, daß Du mit dieser These meinst, daß BjoernMZs System permanent das macht, was Dirac passiv berechnet. Und genau darauf habe ich Dir nach etwas hin und her geantwortet, daß das nicht der Fall sein kann, da es dafür Meßdaten bräuchte.

Ich stelle mir aus IT-Sicht die Frage, was hier eine 100% CPU Zeit veranschlagen sollte

Hat er doch geschrieben. Er betreibt auf einem Intel Core i5 PC pro Kanal Filter mit 200000 Taps (=Koeffezienten, nicht Tabs), zuvor gar von 269000 Taps pro Kanal, und das offensichtlich erfolgreich, und hat versucht das ganze über FIR auf einem Najda DSP zu fahren. Der DSP hat's nicht geschafft.
200000 Koeffizienten pro Kanal sind eine Menge. Audyssey MultEQ XT32 verwendetet mehrere 10tausend, weiß nicht ob insgesamt oder pro Kanal.
Frag mal ChatGPT das da: "How many taps does Dirac Live Room Correction use with its filters?"
Dann bekommst Du auch Info darüber, was so üblich ist: 2048 Taps pro Kanal bei miniDSP DDRC-88D/DA8.
Auf performanteren DSP sind es 12000 Taps über 8 Kanäle, bis hin zu 32000 Taps pro Kanal in hypothetischen Szenarien.

Seine 200000 Taps pro Kanal sind halt offenbar zu viele für den Najda DSP (wie alt ist der denn?).

und warum hier Speicher nicht ausreichen sollte....um das zu verstehen, benötigt man ja zumindest erstmal Wissen um das Gesamtsystem?

Kann man sich selbständig anlesen. AVRs haben nur so viel Speicher wie für die Anwendung vorgesehen. Die sind auf das Norwendigste zugeschnitten. Da sind keine 32+GB wie in einem heutigen PC drin.
Ein Sharc ADSP‑21593 eines Denon X4800H z.B. hat 2x640kB Level 1 SRAM und 2MB Level 2 SRAM. Über Level 3 ginge noch DDR3 bzw. DDR3L Speicher anzubinden. Kann ja mal wer auf den Bildern gucken, ob derartige Chips im X4800H rund um den DSP verbaut sind.

ICH stelle mir maximal vor, wenn Dinge in Echtzeit berechnet werden, dass diese vielleicht so eine Last verursachen. Ich schreibe nicht, dass dieses der Fall ist.

Ich hab keinen Schimmer, wie Du darauf kommst, ich hätte das behauptet.

Übrigens wird alles Audio in jedem raumkorrigierenden System (Trinnov, Dirac, Audyssey, YPAO, ...) in Echtzeit verarbeitet/verrechnet/aus dem Eingangssignal das korrigierte Ausgangssignal berechnet. Was also meinst Du eigendlich mit "wenn Dinge in Echtzeit berechnet werden"?

@Basstrap

Kann man sich selbständig anlesen. AVRs haben nur so viel Speicher wie für die Anwendung vorgesehen. Die sind auf das Norwendigste zugeschnitten. Da sind keine 32+GB wie in einem heutigen PC drin. Ein Sharc ADSP‑21593 eines Denon X4800H z.B. hat 2x640kB Level 1 SRAM und 2MB Level 2 SRAM. Über Level 3 ginge noch DDR3 bzw. DDR3L Speicher anzubinden. Kann ja mal wer auf den Bildern gucken, ob derartige Chips im X4800H rund um den DSP verbaut sind.

Kannst du von deinen Angaben drauf schließen, wieviel Tabs so ein 4800er zu Verfügung hat?

Ich habe natürlich nicht versucht diese Filter in den Najda zu laden. Es sind genau 262.144Tabs pro Kanal...Der Najda hat auch unter 3000 für alle Kanäle..
Ich wollte jetzt auch nicht das Thema zum Acourate Thread machen..Aber die vernünftige Rechenlesitung für so ein Dirac System liegt irgendwo in der Mitte zwischen PC Convolver und dem was jetzt an AVRs auf den Markt kommt..

Was mich viel mehr Rätselt, wenn ich jetzt alle Lautsprecher hinter mir zu Support mache, um die Main Speaker perfekt im Raum klingen zulassen, geht dann noch Mehrkanal?
Das müsste dann schon in echtzeit berechnet und quasi neu abgemischt werden...

BjoernMZ (Beitrag #3475) schrieb:

Was mich viel mehr Rätselt, wenn ich jetzt alle Lautsprecher hinter mir zu Support mache, um die Main Speaker perfekt im Raum klingen zulassen, geht dann noch Mehrkanal?

Dazu werden doch nur mehrere Signale zusammengemischt, die Support-Signale mit dem Signal des für den Lautsprecher zuständigen Kanals. Sowas macht der AVR z.B. beim Downmix von 5.1 auf 2.0 oder beim Rendern von Atmos-Objekten auf das Lautsprecher-Layout ja auch.

Das habe ich mir irgendwie komplexer vorgestellt...aber schön das.es so einfach funktioniert...ich dachte support und Wiedergabe muss irgendwie getrennt passieren...

Thema DSP und Co hatte ich mir fast gedacht, dass die ählich wie bei den "normalen" CPUs bestimmte Beschleuniger haben.
"Enhanced FIR and IIR accelerators running up to 1 GHz"
Advanced Hardware Accelerators Enhanced FIR/IIR offload engines running at Core clock frequency for added processing power
aus dem Datenblatt zum genannten DSP ADSP‑21593

Daher ist es wichtig, wovon man überhaupt ausgeht und was man mit was vergleicht.
Hat der nadja dsp ähnliche HW-coded Algorithmen?

Keine Ahnung, der Najda ist schon in die Jahre gekommen...da hat sich sicher einiges getan in Sachen Hardware Beschleunigung....Der Najda war mal kurz, von den Features und Kanal Anzahl, der beste DSP für Lautsprecher Aktivirung, aber auch nicht der stabilste...und meiner hat bei 8 Kanälen den Hochton ganz subtil versaut...

DAS war aber die ganze Zeit mein Anliegen. Erstmal die Grundlage zu schaffen um zu verstehen, warum Du auf Plattform 1 andere Ergebnisse erziehlst als auf Plattform 2 (daher auch das Missverständnis meinerseits in Bezug auf die Berechnungen, da ich Deine HW nicht kenne und den Aufbau dazu).
Intel GPUs sind spieletechnisch besch...weil sie halt nicht optimiert sind für Spiele, verglichen mit NVIDIA-GPUs z.B..... bei CPUs / SoCs / DSPs ist es das gleiche. Die Teile sind für bestimmte Dinge spezialisiert, ergo können sie einige Dinge gut, andere nicht. Dass Dein DSP "schleift" könnte vielleicht daran liegen, dass er eben nicht für diese Art der Berechnung optimiert ist und hier via Software das Ganze emulieren muss. Ergo fällt die Leistung entsprechend mager aus. Hardwareverdrahtes Coding für bestimmte Berechnungen kann man halt nicht vergleichen mit Emulierung über eine SW-basierte Lösung.

Deswegen kannst Du hier keine direkten Vergleiche ziehen. Den Speicherbedarf und die benötigte Rechenleistung auf DSPs kann man sicherlich auch berechnen.... das kann gerne basstrap übernehmen.

Ich bin da pos. Dinge wenn ART auf meinen Cinema 50 kommt (wenn es denn kommt).

AudioControl ist nun auch dabei: Link


Der 11ch-AVR ist GaN-FET powered

pogopogo (Beitrag #7) schrieb:

Hier eine Aussage zu DLART von miniDSP: Link

Mal schauen, ob 'ready to ship' noch dieses Jahr ausgerufen wird

Was interessiert eine Meldung von 2023? Fast 3 Jahre her?

Monologe sind halt per se zeitlos. Und füllten schon immer ein Sommerloch.

Er wollte etwas schreiben um die Quote zu erfüllen und was gibt es schöneres als sich selbst zu zitieren

3475 Beiträge später

Circle of life.

Aber wir werden es herausfinden. Oder zumindest lang und breit zitiert und verlinkt bekommen.