Sorry, aber ich habe Zweifel an einigen Deiner Bemerkungen, die klingen für
mein Verständnis irgendwie nicht logisch. Es mag sein, dass ich mich auch irre,
aber sieh bitte mal hier:
> Das ist wohl eher so, dass der Treiber gewisse Blockgrössen anbietet für das Gerät.
>Die sind natürlich dann auf dieses Gerät optimiert. Es wird nicht jedes Sample einzeln
>berechnet und wietergegeben, sondern immer ein ganzer Block als Datenpaket.
Im Grunde genommen ist ein Recording Interface erstmal auch nichts anderes als ein serielles Interface. Da werden Daten von analog in digitale Werte umgewandelt und irgendwann sendet der Treiber einen Interrupt, dass die CPU bitte mal eine Low Level Interruptroutine ausführen soll, um Daten abzuholen. Die etwas komplexeren Routinen, die dann diese Arbeit ausführen sind soweit ich das kapiert habe die DPCs, Deferred Prozedure Calls. Und auf einem höheren Layer wird dann alles noch ein bisschen zusammengepackt und in "n Samples" via ASIO Layer übertragen. Irgendwie so ...
Der ASIO Treiber erledigt einfach i/o Aufgaben effizient am Windows Sound System vorbei.
Der ASIO Treiber ist auf das Gerät optimiert.
Aber die Buffersize (ob 32 oder 48 oder was auch immer) ist einfach "nur" eine Anzahl Samples, die in einem Rutsch gelesen oder geschrieben werden sollen. Liest man mit (zu) kleinen Buffersizes, dann steigt die Zahl der HW Interrupts ("da ist wieder was am Interface abzuholen"), damit wird die CPU häufiger mit Interrupt Verarbeitung / Treiber Routinen beschäftigt.
>Die interne Blockgrösse ist die mit der S1 intern arbeitet.
>Die interne Blockgrösse kann bei S1 nicht höher sein als die Geräteblockgrösse
Die ASIO Buffersize dient erstmal dem reinen Datentransfer. Danach benötigt S1 Rechenzeit für sich selbst und etwaige Plugins. Wie S1 die Samples dann intern weiterverarbeitet, in verschiedene Queues steckt oder noch über VSTs weiterberechnen läßt, das läuft auf einer ganz anderen Ebene ab, das ist die Applikationsebene.
Ich verstehe S1 / den screenshot im unteren Bereich so, dass die dort angezeigten Samples halt von dem konkreten Projekt abhängen, wieviele Spuren und VSTs sich darin befinden und wie komplex die Berechnungen der einzelnen VSTs sind. Darum sind die Werte höher.
Ich verstehe nun nicht an Deiner Aussage, warum die ASIO Buffersize ggf nicht optimal auf die interne Buffersize abgestimmt sein soll. Hauptsache die Samples (die Daten) sind erstmal da und werden dann in der DAW "nach ihrer eigenen Methode" weiterverarbeitet.
Du sagst das ja so, als würde eine "nicht passende" ASIO Buffersize zu einer ineffizienten Bearbeitung der samples DAW intern führen. Nach meinem Verständnis händen die Dinge nicht in der von Dir beschriebenen Form voneinander ab.
Bei ner SSD kann aus physikalischen/technischen Gründen (so ists halt designed bzw von der "Physik der Speicherzelle" vorgegeben) ein schlechtes Alignment dazu führen, dass für 1 Datenblock 2 Speicherzellen statt einer beschrieben werden (doppelte Abnutzung+ineffizientere Datenübertragung). Aber eine ASIO Buffersize ist nicht "unpassend" zu einer bestimmten Latenz, die sich durch die Interne DAW Bearbeitung ergibt. S1 hat diese Zeit m.E. einfach nur noch mal in einem anderen Format, nämlich Samples, ausgegeben, weil bei einer bestimmten Sample Rate, zB 44.1 Khz, ein Sample eine bestimmte Zeitdauer hat.
Bei 44.1 KHz sampling rate dauert ein sample halt 1/44100 = 23µs.
Bei einer Buffersize von 128 Samples sind das dann schon 2,092ms.
1,09ms sind halt 1,09/0,023 = 48 Samples.
Und 3,99 und 8,10ms sind dann halt auch eine gewisse Anzahl von Samples.
Aber die Datenübertragung für i/o (ASIO Buffersize) solltest Du halt einfach nur darauf hin optimieren, dass Dein Gerät es einfach problemlos schafft, die Daten schnell genug ranzukarren und sie wieder loszuwerden.
>Wenn aber das Gerät z.b. mit 200 Samples arbeitet und S1 mit 128 Samples pro Block
> muss S1 sich 2 mal Daten vom Treiber abholen oder dahin verschicken, weil halt
> beim ersten Transfer 72 Bytes "liegenbleiben". S1 muss die aber beim 2. Durchgang
> als 128-Sampleblock verschicken obwohl ja nur noch 72 Samples anliegen...
> Das ist ein unnötiger "Datenverschnitt".
> Optimal ist also ein ganzzahliges Vlelfaches zwischen Geräte- und Interner Blockgrösse.
Das sehe ich anders. Ich denke das stimmt einfach nicht so wie Du das schreibst.
Ich würde mal schwer davon ausgehen, dass das was S1 da im unteren Bereich anzeigt die Latenz ist, die S1 ja nach Projekt und geladenen Plugins benötigt, um Audiodaten intern fertig berechnet zu bekommen. Der Datentransport für die i/o mittels ASIO und die Buffersize laufen neben der internen Verarbeitung der DAW ab.
Wichtig ist halt nur, den richtigen Kompromiss zu finden zwischen near-realtime Anforderungen (geringe Latenz) und zuverlässig arbeitendem System (keine Drops) bei Last. Wobei zu geringe ASIO Buffersizes selber auch mehr Interrupts und CPU Last verursachen.
> Die Latenz an sich hängt sicher auch noch von der Bittiefe ab.
> In deinem Beispiel sind es 32 bit. 16 bit sollte schneller sein.
Die Bittiefe bestimmt den Dynamikumfang des Signals. Die CPUen haben heutzutage 64bit breite Register, ob davon nur 8, 16 oder 32 bit belegt werden macht die Rechenoperationen nicht schneller oder langsamer.
