Bouncen und Prozessorkerne

[Tiefton]

Kann mir nicht vorstellen, dass das technisch nicht machbar ist. Wahrscheinlich eher viel Aufwand. Prinzipiell wäre es doch möglich pro Kern mehrere Spuren zu bouncen und diese am Ende "zusammenzufügen".. und dies ist sicherlich nicht trivial...

Werden gefreezte Spuren eigentlich schneller (offline) gebounced?

[Lolo]

wenn mfritze sagt, daß es nicht geht, oder zumindest sehr, sehr schwer, dann glaub ich ihm das. der programmiert das zeug doch...
vielleicht würde in dem von dir genannten beispiel auch die prozessorbelastung gesenkt, bzw. auf andere verteilt, aber nicht die geschindigkeit beim bouncen erhöht. insofern wäre das dann sinnlos. da hat man doch lieber 1 prozessor 100% ausgelastet und die anderen frei, als alle prozessoren mit 20% voll aber nicht (wesentlich) schneller.

[maiermueller]

Kann mir nicht vorstellen, dass das technisch nicht machbar ist. Wahrscheinlich eher viel Aufwand. Prinzipiell wäre es doch möglich pro Kern mehrere Spuren zu bouncen und diese am Ende "zusammenzufügen".. und dies ist sicherlich nicht trivial...

Schöne Vorstellung, aber leider nicht umsetzbar. Denn was machst Du, wenn z.B. alle Spuren einen Send auf einen Reverb haben? Nach Deiner Methode müßte der Reverb dann ja für jede Spur extra berechnet werden, denn Spur 1 enthält vielleicht nur einen ES-1, der ganz schnell berechnet ist, Spur 2 jedoch einen Nexus, der 50x solange braucht. Ansonsten müßte Spur 1 auf Spur 2 warten, damit der Reverb die Sends gleichzeitig bekommt, und dann wären wir wieder da, wo wir jetzt auch sind.

Und wenn man nun den Reverb-Send für jede Spur extra berechnen würde? Das hätte klanglich vielleicht noch gar keinen so großen Einfluss auf das spätere Zusammenmischen - nicht aber z.B. bei GitarrenAmps oder anderen Verzerrern, oder gar Kompressoren, denn da ist das klangliche Resultat immens abhängig vom jeweiligen Eingangsignal.

Man kann also nicht ohne weiteres den Offline Bounce auf mehrere Threads verteilen.

Möglichkeit #1:
Logic analysiert, wie viele unabhängige Signalflüsse in einem Song vorhanden sind und berechnet diese in mehreren Threads. Ob dies allerdings so einfach ist, kann ich nicht sagen. Und auch dann ist nicht garantiert, dass alle Kerne voll ausgelastet sind, das ist dann eben extrem projektabhängig.

Möglichkeit#2:
Logic spielt den Song einfach mit variabler Geschwindigkeit, und zwar immer mit der höchstmöglichen, ab. Das heißt, mindestens ein Kern läuft immer bei 100%, die anderen richten sich nach diesem. Auch das wäre sehr projektabhängig...

Immerhin, ganz utopisch ist es meiner Meinung nach nicht, die Offline-Bouncegeschwindigkeit zu steigern. Aber dass alle Kerne voll ausgelastet sind, das geht schlicht und ergreifend nicht!

Werden gefreezte Spuren eigentlich schneller (offline) gebounced?

Klar! Das sind ja nur banale Audiofiles!

[stef]

Schöne Vorstellung, aber leider nicht umsetzbar. Denn was machst Du, wenn z.B. alle Spuren einen Send auf einen Reverb haben? Nach Deiner Methode müßte der Reverb dann ja für jede Spur extra berechnet werden, denn Spur 1 enthält vielleicht nur einen ES-1, der ganz schnell berechnet ist, Spur 2 jedoch einen Nexus, der 50x solange braucht. Ansonsten müßte Spur 1 auf Spur 2 warten, damit der Reverb die Sends gleichzeitig bekommt, und dann wären wir wieder da, wo wir jetzt auch sind.

Schlechtes Beispiel! Ich sehe überhaupt kein Problem darin z.B. 16KB-Puffer zu nehmen, drei Spuren auf drei Kernen zu berechnen, diese drei Puffer den Sendlevels entsprechend zu mischen und die Additionsergebnisse in den Hall zu schicken. Bei einem Faltungshall ist ein 16 KB-Puffer natürlich ruckzuck zu klein; da müsste Logic dann gucken wie lang ist der Hall (z.B 10 s), wie ist die Samplerate (z.B. 44100 Hz), macht bei 32Bit dann ca. 1,8 MB.
Wenn man jetzt Wert auf einen 1000 s Send-Hall auf 200 Spuren legt wäre eine 64Bit-Version on Logic schon wünschenswert :-)
Kniffliger finde ich da Sidechains; damit die funktionieren braucht man kleine Puffer. Wenn das Projekt den Rechner eh schon an die Wand drückt, bringt das dann nix mehr, aber wenn man noch Luft hat, könnte das bouncen trotzdem schneller gehen.

Stef

[Tiefton]

Wieso dann nicht mehrere Spuren einzeln parallel gleichzeitig bouncen (jeweils auf verschiedenen Kernen bzw. auch Threads) und danach einen Gesamtbounce auf einem Prozessor? Wäre mit Sicherheit auch schneller... (zumindest bei Audioinstrumenten ohne Effekte...)

Oder irgendwie sowas:
Zuerst wird analysiert welche Kanäle von welchen Abhängen und von welchen nicht.. Diese werden zu einem "Block" zusammengefasst und jeweils von einem Prozessor gebounced (dürfte ja kein Problem sein).

Summen, die nicht voneinander abhängig sind, können am Ende doch "einfach" addiert werden - was natürlich sequenziell ist und am Ende durchgeführt werden muss, da sonst die "Ergebnisse" der einzelnen Spuren/Busse nicht zur Verfügung stehen...

Bin selbst Informatiker, wenn auch in einer anderen Ecke (Datenbanken, WebServices, ...).

[stef]

Wieso dann nicht mehrere Spuren einzeln parallel gleichzeitig bouncen (jeweils auf verschiedenen Kernen bzw. auch Threads) und danach einen Gesamtbounce auf einem Prozessor? Wäre mit Sicherheit auch schneller... (zumindest bei Audioinstrumenten ohne Effekte...)

Oder irgendwie sowas:
Zuerst wird analysiert welche Kanäle von welchen Abhängen und von welchen nicht.. Diese werden zu einem "Block" zusammengefasst und jeweils von einem Prozessor gebounced (dürfte ja kein Problem sein).

Summen, die nicht voneinander abhängig sind, können am Ende doch "einfach" addiert werden - was natürlich sequenziell ist und am Ende durchgeführt werden muss, da sonst die "Ergebnisse" der einzelnen Spuren/Busse nicht zur Verfügung stehen...

Bin selbst Informatiker, wenn auch in einer anderen Ecke (Datenbanken, WebServices, ...).

Ich denke auch, dass das Problem lösbar ist. In der Regel werden die meisten Spuren mit ein paar Inserts direkt auf den Ausgang gehen. Nur muss die Puffergröße bei Verwendung von Seitensträngen klein sein, damit dieser schnell genug regelnd eingreifen kann.

[KellerKnabe]

Also meine Sicht der Dinge ist die Folgende:
Bouncen ist mal prinzipiell immer dass Selbe, egal ob offline oder online.
Irgendwo her kommt eine Clock, die den "Takt" für das Bouncen vorgibt - bei Online zB CoreAudio, bei Offine der Host (Logic).
Nur wird die Bearbeitung im Online-Fall dem OS (CA) übergeben und im Offline-Fall kümmert sich der Host darum. D.h. alles was in Richtung Multithreading geht, muss vom Host selbst verwaltet werden, was einen immensen Aufwand bedeuten kann.
Vielleicht "wartet" Apple mit der Multithreading-Unterstützung noch auf SchneeLeo, der das ja "von Haus aus" anbietet ... ich bin immer noch guter Hoffnung, dass ich meine Wette nicht verliere ...

[maiermueller]

Schlechtes Beispiel! Ich sehe überhaupt kein Problem darin z.B. 16KB-Puffer zu nehmen, drei Spuren auf drei Kernen zu berechnen, diese drei Puffer den Sendlevels entsprechend zu mischen und die Additionsergebnisse in den Hall zu schicken. Bei einem Faltungshall ist ein 16 KB-Puffer natürlich ruckzuck zu klein; da müsste Logic dann gucken wie lang ist der Hall (z.B 10 s), wie ist die Samplerate (z.B. 44100 Hz), macht bei 32Bit dann ca. 1,8 MB.
Wenn man jetzt Wert auf einen 1000 s Send-Hall auf 200 Spuren legt wäre eine 64Bit-Version on Logic schon wünschenswert :-)
Kniffliger finde ich da Sidechains; damit die funktionieren braucht man kleine Puffer. Wenn das Projekt den Rechner eh schon an die Wand drückt, bringt das dann nix mehr, aber wenn man noch Luft hat, könnte das bouncen trotzdem schneller gehen.

Stef

Denkfehler! ;-)

Du gehst davon aus, dass die drei Spuren in der gleichen Zeit berechnet werden. Das ist aber falsch. Eine Spur kann z.B. in 0.001 ms berechnet sein, während die andere 2 min braucht. Muss man also mit dem Weiterrechnen des Halls in jedem Fall 2 min warten. Mit Puffern an sich hat das nichts zu tun, allein mit der Rechenzeit pro Sample...

Ich denke auch, dass das Problem lösbar ist. In der Regel werden die meisten Spuren mit ein paar Inserts direkt auf den Ausgang gehen. Nur muss die Puffergröße bei Verwendung von Seitensträngen klein sein, damit dieser schnell genug regelnd eingreifen kann.

Mehrere Denkfehler! ;) ;)

"In der Regel" ist jedes Projekt komplett anders und man kann von nichts ausgehen!
Die Puffergröße hat beim Offline-Bounce keine Auswirkung auf irgendetwas. Jedes Sample findet seinen weg durch den Algorithmusdschungel, ganz gleich, wie groß der Puffer ist, in dem es schwimmt. Da es beim Offline-Bounce nicht auf die Berechnung innerhalb einer festgelegten Zeit (Echtzeit) ankommt, können die Puffer vielmehr beliebig gewählt werden.

[maiermueller]

Wieso dann nicht mehrere Spuren einzeln parallel gleichzeitig bouncen (jeweils auf verschiedenen Kernen bzw. auch Threads) und danach einen Gesamtbounce auf einem Prozessor? Wäre mit Sicherheit auch schneller... (zumindest bei Audioinstrumenten ohne Effekte...)

Oder irgendwie sowas:
Zuerst wird analysiert welche Kanäle von welchen Abhängen und von welchen nicht.. Diese werden zu einem "Block" zusammengefasst und jeweils von einem Prozessor gebounced (dürfte ja kein Problem sein).

Summen, die nicht voneinander abhängig sind, können am Ende doch "einfach" addiert werden - was natürlich sequenziell ist und am Ende durchgeführt werden muss, da sonst die "Ergebnisse" der einzelnen Spuren/Busse nicht zur Verfügung stehen...

Bin selbst Informatiker, wenn auch in einer anderen Ecke (Datenbanken, WebServices, ...).

Das würde meiner Möglichkeit #1 entsprechen...

Bin zwar kein Informatiker, habe aber längere Zeit Audioalgorithmen programmiert... :)

[maiermueller]

Also meine Sicht der Dinge ist die Folgende:
Bouncen ist mal prinzipiell immer dass Selbe, egal ob offline oder online.
Irgendwo her kommt eine Clock, die den "Takt" für das Bouncen vorgibt - bei Online zB CoreAudio, bei Offine der Host (Logic).
Nur wird die Bearbeitung im Online-Fall dem OS (CA) übergeben und im Offline-Fall kümmert sich der Host darum. D.h. alles was in Richtung Multithreading geht, muss vom Host selbst verwaltet werden, was einen immensen Aufwand bedeuten kann.
Vielleicht "wartet" Apple mit der Multithreading-Unterstützung noch auf SchneeLeo, der das ja "von Haus aus" anbietet ... ich bin immer noch guter Hoffnung, dass ich meine Wette nicht verliere ...

Nein, das stimmt so nicht. Das Gegenteil ist der Fall: offline bouncen wird eben genau ohne Clock gemacht, nämlich so schnell, wie es geht. Das ist ein fundamentaler Unterschied. Und deshalb funktioniert es auch nur in einem Thread, da dann alle Samples nacheinander berechnet werden müssen.

Vielleicht kann man es so darstellen:
- Beim Onlinebounce kümmern sich die Channels um die Produktion der Audiodaten und werfen sie auf den Output. Das Ergebnis hört man dann direkt in Echtzeit.
- Beim Offlinebounce zieht man das Pferd von hinten auf: man sagt, "ok, wo kommt Outputsample #1 her?", und rechnet den ganzen Quatsch durch. Dann ist Sample #2 dran usw.

Wie gesagt, prinzipiell müßte es schon machbar sein, ein Projekt in voneinander unabhängige Aufgaben zu unterteilen und diese dann ein separate Threads zu packen, die jeweils auf die Kerne verteilt werden, um das ganze dann am Schluss zu summieren. Trotzdem wird man es auch damit nicht schaffen, ein Projekt mit Volldampf unter 100%iger Auslastung aller Kerne zu berechnen. Eher wird es so ne Art "beschleunigter Bounce" sein...

[hugoderwolf]

Nein, das stimmt so nicht. Das Gegenteil ist der Fall: offline bouncen wird eben genau ohne Clock gemacht, nämlich so schnell, wie es geht. Das ist ein fundamentaler Unterschied. Und deshalb funktioniert es auch nur in einem Thread, da dann alle Samples nacheinander berechnet werden müssen.

Ist ja nicht gesagt, dass das so sein muss. Udo meinte mit Clocking nicht die Synchronisation mit der Echtzeit sondern das Anstoßen eines Berechnungszyklus.

In Echtzeit läufts folgendermaßen:
Core Audio sagt Logic "bitte gib mir mal die nächsten x Samples", wobei x der eingestellten Puffegröße entspricht. Logic schmeißt dann die Audioengine an, die irgendwie alle Cores in Bewegung setzt um die nächsten x Samples liefern zu können. Core Audio bekommt die dann und spielt das Ganze übers Interface raus. Wenn Online gebouncet wird wandern die Sampleblöcke dann gleichzeitig noch auf die Festplatte.

Im Offlinemodus *könnte* es dann mit dem gleichen Mechanismus laufen, nur dass die "nächsten x Samples" nicht von Core Audio sondern von irgendeiner Offline-Bounce-Methode angefordert werden.

Von daher könnte man schon behaupten, dass das ohne Probleme zu schaffen wäre. Aber aus meiner eigenen Erfahrung als Softwareentwickler weiß ich, dass es längst umgesetzt wäre, wenn es tatsächlich so trivial wäre. Mit Sicherheit liegt da irgendwo ein dicker Klops im Wege, den wir ohne Einsicht in den Code hier sicher nicht finden werden.

(Man soll nicht meinen, da wären völlige Idioten am Werk. Da sitzen Profis, und mit Profis meine ich nicht x-beliebige Informatiker sondern Spezialisten mit zig Jahren Erfahrung in *genau* diesen Dingen. Das sind keine Probleme, die für Ferndiagnose geeignet wären... ;))

[Djordji]

Aber es könnte so funktionieren.
Der ertse Prozessor checkt was gemacht werden muss und die anderen helfen ihm bei der anstehenden Arbeit.

Also nicht gleich von Anfang an die Arbeit auf alle verteilen. Sondern gleich nachdem der erste die Informationen gesammlt hat was gemacht werden muss.

Das geht auf sicher.

[Saxer]

ok, so machen wir´s!

[Dr.Wu]

ich bounce immer realtime weil ich zuviele streaming plugs verwende, die beim offline bouncen gerne mal artefakte produzieren.......
aber da meine stücke meistens unter der 4 minuten grenze liegen isses mir egal

[maiermueller]

Ist ja nicht gesagt, dass das so sein muss. Udo meinte mit Clocking nicht die Synchronisation mit der Echtzeit sondern das Anstoßen eines Berechnungszyklus.

Naja, aber ne Clock hat ja schon immer eher was periodisches, zumindest im eigentlichen Sinne des Wortes. Und das bedeutet dann: X Samples pro Zeit. Genau das macht der jetzige Offline-Bounce aber nicht. Der rechnet einfach, wie's kommt, indem genau die taktgebende Clock weggelassen wird. Weil dann die Threads einfach drauf los rennen, müssen sie in einen einzigen Thread gepackt werden, da sie sonst "auseinanderlaufen" würden.

Von daher könnte man schon behaupten, dass das ohne Probleme zu schaffen wäre.

Was wäre denn nun genau zu schaffen? Einen "Speed-Bounce" oder das Auslasten aller Kerne auf 100%? Darum ging's mir ja... ;)