VST im Vergleich zu (VA) Hardware

mink99 schrieb:
Irgendwann wird für vsts Cuda kommen, und dann wird's spannend.
Spricht eigentlich schon heute nix dagegen, außer das Wikipedia sagt:

"Ein anderer Nachteil ist die Anbindung an die Rechnerarchitektur, sie erfolgt bei aktuellen GPUs meist über PCIe und bringt, im Vergleich zur direkten Anbindung von Prozessoren, schlechtere (höhere) Latenzzeiten und geringere I/O-Durchsatzraten mit sich."

Klingt für VSTs nicht so richtig vielversprechend. Da müsste dann halt noch ein Displayport auf Audiointerface Adapter dran. Wäre cool, ist aber glaube ich von niemandem geplant.

Richtig flott sind die Grafikkarte ja glaube ich eh nur beim Matrizenrechnen. Das wäre zwar vermutlich zum lösen von Differentialgleichungen toll, das macht aber bis jetzt kaum ein Synth (Ich glaube Pianotec, evtl. die lustigen neuen Filteremulationen, da hab ich mich aber nicht eingelesen, also nix glauben)..
 
microbug schrieb:
Wenn ein normaler Desktoprechner einen solchen Synth fahren soll, dann muß er den DSP per Software emulieren, was ordentlich Rechenleistung braucht.
...
Nun hat aber so ein Rechner ja noch etliches Anderes zu tun als nur den Synth zu fahren, dieser ist also eine Anwendung von Vielen, daher muß der Synth sich die Leistung mit anderen Softwareschnippeln teilen, ohne daß man als Nutzer da den großen Einfluß drauf hätte.

Ein Hardware-VA oder Digitalsynth braucht daher wesentlich weniger Rechenpower als eine Plugin-Lösung.
...
... Das Ding als Plugin bräuchte ein Vielfaches an Rechenleistung, um auf aktueller Rechnerhardware nebst modernen OS so zu laufen, und es würde auch noch anders klingen.
...
Ein digitaler Hardwaresynth ist fast immer optimiert, sieht man mal von Schnickschnackkisten wie dem Kronos ab.
Bitte nicht übelnehmen, aber da sammelt sich schon einiges an "Hörensagen", oder zumindest klingt das so.

Erstmal braucht ein Plugin (so auf der bit und byte "Ebene") exakt die gleiche Menge an Operationen wie der gleiche Algoritthmus auf einem DSP oder einem speziellen Chip, solange DSP und CPU die gleichen Operationen unterstützen.

Das ist natürlich nicht immer so, da DSPs so manches seltsame können. Die wichtigste DSP Funktion zur Verarbeitung von großen Datenmengen , nämlich SIMD wird inzwischen auch von so ziemlich jeder CPU unterstützt. Es gibt denke ich noch bei der einen oder anderen Operation Unterschiede in der Zyklenzahl, die ein CPU bzw. ein DSP so braucht um sie auszuführen. Die Pipelinelänge moderner CPUs sollte übrigens bei der Audioverarbeitung so ziemlich egal sein, da da fast keine Sprünge (zumindest keine unerwarteten) durchgeführt werden.

Was bei Audioanwendungen potentiell "weh tut" ist, dass moderne CPUs intern häufig deutlich höher getaktet sind als der Hauptspeicher. Im schlimmsten Fall bremst damit nicht die CPU sondern der Hauptspeicher. Nachdem die Speicher und Busse in den letzten paar Jahren aber deutlich flotter geworden sind sollte das nicht mehr so schlimm sein.

Auch die Tatsache, dass auf modernen Rechnern ganz viel Kram im Hintergrund läuft ist nicht so schlimm. Wo das weh tut ist bei der Latenzzeit, da natürlich unerwartete CPU und Buslast das Timing versaut. Nachdem ich elend inkompetent in seriöser Computeroptimierung bin hab ich so 8ms + Wandlerlatenz auf meinem Rechner. Das ist OK und stört nicht wirklich, ist aber nicht fantastisch. Anständig optimierte Audiorechner kommen aber durchaus auf 2ms oder so. Das schaffen nicht alle Hardwarekisten (es gab irgendwo mal einen lustigen Thread, wo jemand Latenzzeiten und Latenzjitter von Analogsynthies und HW-Drummachines gemessen hat. War teilweise erschreckend).

Die CPU-Last des Hintergrundkrams ist meist < 10%, macht also nicht viel kaputt. Auch das Registerdumpen beim Multithreaden sollte nicht soooo schlimm sein.

Ich denke, das teilweise bei HW-Synthis noch mehr "beschummelt" wird um Rechenzeit zu sparen. Der DSI Pym hat neulich mal gepostet, das die typische Kontrollgeschwindigkeit bei digital kontrollierten Analogsynths so 2kHz ist. Ich geh mal davon aus, dass sie bei manchem Digitalem noch weit darunter liegt. Zudem gibts natürlich diverse Tricks, wie das nutzen von logarithmischer Wellenformdarstellung um eine Hüllkurven-Multiplikation durch eine Addition zu ersetzen.

microbug ist ja, wenn ich mich recht erinnere auch Kurzweil Nutzer/Fan. Wenn man mal so drüber nachdenkt, was die schicken VAST DSP-Blöcke so tun, so fällt einem auf, dass das meist nur 1-2 DSP-Operationen sind (z.B. 1x MultiplyAdd und ein Table-lookup). Das traut sich in der Plugin-Welt kein Mensch.

Manches davon ist schlau und wurde nur von den meisten Pluginprogrammiern vergessen, manche ist einfach Pfusch. Der rächt sich auch manchmal bitter. So bricht beim Blofeld die Stimmenzahl gerne mal ein wenn man zwei Kammfilter nutzt weil ihm der Speicher ausgeht!

Nebenbei sagt die Internetgerüchteküche auch, dass die Software der obengenannten Schnickschnackkisten ziemlich ausführlich optimiert wurde. Sonst würde das bisschen Atom auch den ganzen Schnickschnack nicht stemmen.

Hoffe der Post war nicht zu "Internetnölig", teilweise geht mir, bei aller liebe zu meinen gesammelten Spielzeugen, der verbreitete Hardwaremystizismus aber gegen den Strich.
 
101010oxo schrieb:
Das waren Kilobyte...

Dammich, natürlich. Bin auch schon versaut.

Was die Berechnungen in Echtzeit betrifft, so versucht man diese, egal in welcher Umgebung, möglichst zu vermeiden. Zu Zeiten von 8bit CPUs arbeitete man schon mit Tabellen, das ist heute kaum anders, geht einfach schneller.

Die Tricks gibt's ja auch bei der Hardware. Die Alesis SR-16 ist eine 8031-Architektur, also 8Bit, wie schon die HR-16 davor auch. Beide haben zum Auslesen der Samples einen ASIC, die MCU steuert nur. Bei der SR-16 hört man bei manchen Sounds Hallfanhnen. Das sind aber Samples, die durch den ASIC geschickt kombiniert werden, was die SR-16 noch an einigen anderen Stellen macht. Ich hatte mal die ROMs ausgelesen und mir genauer angeschaut, einfach aus Neugierde.

Kurzweil ist da schon ein spezielles Kapitel. Wobei ich mich immer frage, ob es nötig war, sich Custom-DSPs bauen zu lassen statt handelsübliche zu nehmen.

Nochmal zum Blofeld: mit einem dickeren Prozessor als dem 9S12 wäre der an einigen Stellen weniger wackelig, aber auch deutlich teurer in der Herstellung gewesen. Der beim MicroQ verwendete 683xx kostet selbst bei 100Stck noch das Doppelte eines 9S12 und braucht zudem noch externen Flashspeicher, das wollte man offenbar verneiden.Die bei Anderen verwendeten H8 oder SuperH liegen in ähnlichen Preislagen.
 


Neueste Beiträge

Zurück
Oben