Blockgröße / Latenz

  • Ersteller Novalis
  • Erstellt am
Novalis

Novalis

Registriert
27.01.13
Beiträge
1.151
Reaktionen
322
Punkte
2.154
Hallo,

ich wollte schon länger wissen, warum in den Audioeinstellungen unter "Eingans- und Ausgangslatenz" eine andere Anzahl an Samples steht, als bei der Geräte- und der internen Blockgröße:

puflegph34.jpg


Kennst sich da jemand aus, und könnte mir das bitte erläutern? :)
Ist eine reine Interessensfrage.
 
Das obere ist die Abstimmung mit Deinem Audiotreiber.
Geräte Blockgröße ist das auf was der Audiotreiber eingstellt ist und die interne dann entsprechend die mit der S1 arbeitet.

Die Ein- und Ausgangslatenz aber ist das was S1 für die Latenzkompensation berechnet. Diese kann sich je nach geladenen Plugins ändern. Selbst bei leerem Projekt ist die Ausgangslatenz etwas höher, weil S1 ja selbst auch eine gewisse Latenz hat.

_Markus
 
Also muss man das so verstehen, dass S1 sozusagen eine best. Menge an Samples zur Latenz des Audiotreibers hinzufügt?

Also bei der Eingangslatenz wären das dann im vorliegenden Fall 128 Samples Latenz vom Audiotreiber + 48 Samples von S1, was dann insgesamt 176 Samples ergibt.
Und analog dazu bei der Ausgangslatenz wieder 128 vom Audiotreiber und 229 von S1 (=357).
Ist diese Sichtweise richtig?

Ist bei diesen Latenzwerten eigentlich schon die Latenz der A/D und D/A-Wandler mitberücksichtigt?
 
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.

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.


Also wird da auch nichts zusammengezählt.

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.

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.
 
Hallo,

ich glaube das es eher mit dem Interface Treiber und nichts mit S1 zu tun hat. Die Latenz durch die Plugins wird in S1 ja gleich neben der Leistungsanzeige angezeigt und ändert sich bei mir mit der Art der Plugins (siehe unten).
Dagegen ist die Anzeige von Eingangs- und Ausgangslatenz bei meinem Interface immer konsistent mit den Einstellungen. (siehe unten)

Mein Interface ist via PCI verbunden. Vielleicht werden die zusätzlichen Samples von der USB Schnittstelle gebraucht? :schulterzuck:
 

Anhänge

  • S1-1.jpg
    S1-1.jpg
    55,1 KB · Aufrufe: 173
  • S1-2.jpg
    S1-2.jpg
    9,5 KB · Aufrufe: 168
Wenn aber das Gerät z.b. mit 200 Samples arbeitet und S1 mit 128 Samples pro Block

Das Gerät aber arbeitet ja in dem Fall mit 128 Samples, genauso wie S1.
Die Frage ist, wie die unterschiedliche Sample-Anzahl unter "Latenz" zustande kommt.

@ rufio

Da schau her, bei dir ist es ja identisch.
Ist nehme ich mal an bei allen Puffergrößen so?
 
Hallo,

ja, das ist bei allen Puffergrößen so, für 128 z.B. siehe screenshot 1 unten.

Stelle ich nun aber zum Beispiel mein per USB angeschlossenes Tonelab als Interface ein, dann sieht das schon etwas merkwürdiger aus (siehe screeshot 2 unten)

Deshalb nehme ich an, diese Angaben hängen vom verwendeten Treiber ab.
 

Anhänge

  • S1-3.jpg
    S1-3.jpg
    52,9 KB · Aufrufe: 169
  • S1-4.jpg
    S1-4.jpg
    53,9 KB · Aufrufe: 162
Soweit ich das weiss kommt bei USB + Firewire immer noch ein Sicherheitsbuffer dazu deswegen erhöht sich immer ein Wert. Steht zumindest in der RME Anleitung für mein Fireface drin. Bei PCI entfällt wohl der Buffer weil er direht DMA Anschluss hat. Ich denke was da steht kommt wohl auch für die Interfaces der anderen Hersteller in Betracht.

Steht ab Seite 84

http://www.rme-audio.de/download/fface_uc_d.pdf

Vielleicht hilft dir das ja schon weiter.
 

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.
 

Neue Antworten


Oft gelesene Themen

Zurück
Oben