Wieso ist Eingangslatenz != Ausgangslatenz?

t0nno

t0nno

Registriert
03.05.07
Beiträge
344
Reaktionen
11
Punkte
428
Wieso ist Eingangslatenz != Ausgangslatenz?
Beides hat doch die selbe Puffergröße,

Und was definiert eigentlich die Eingangs-/Ausgangslatenz?
 
Hast du doch gerade selbst begründet.
 
nene mit != mein ich UNgleich ^^

bei mir hab ich z.b. bei ner samplefrequenz von 44.1khz und ner latenzeinstellung von 7ms eine eingangslatenz von 9.34ms und eine ausgangslatenz von 7ms.
die eingangslatenz ist übrigens IMMER ~2.34ms höher als die ausgangslatenz, warum nur?
 
naja wahrscheinlich is einfach noch 2,34ms rechenaufwand da um das signal zu DA [g=60]wandler[/g] zu schicken höher als beim AD wandeln ^^
 
und wo ist das Problem mit ungleichen Latenzen?
 
gibt kein problem, ich würds mir nur gern erklären können.
 
[g=539]Cubase[/g] zeigt die Eingangslatenz nicht immer zu 100% korrekt an - das stand jedenfalls mal in einer c't bei einem Soundkartentest.
Die haben dann damals alles bei deaktiviertem "Eingangslatenz ausgleichen" nachgemessen und diese Testergebnisse dann als "echte" Eingangslatenz im Heft abgedruckt.

Gruß
Werner
 
um die frage vllt mal gescheit zu beantworten:

Eingangslatenz: die zeit, die dein signal von z.b. deinem mikro braucht, bis es durch den AD [g=60]wandler[/g] gerattert ist und dein sequenzer aufzeichnet.

ausgangslatenz: deine audiospuren im sequenzer benötigen durch die drauf geladenen effekte rechenzeit deines PCs und zusätzlich noch den weg durch den DA [g=60]wandler[/g], bevor das signal deinen boxen und somit deinen ohren hallo sagt.

Addiert man beide Werte, so hast du die gesamtverzögerung, die je nach dem, was du gerade machst bei monitoring mit effekten ( z.b. du spielst Egitarre über Ampsimulation so, dass du im gleichen moment noch hörst, was du spielst, allerdings mit dem [g=182]Amp[/g] aus dem pc) deutlich oder weniger deutlich zu hören ist
 
Tobbes schrieb:
um die frage vllt mal gescheit zu beantworten:

Eingangslatenz: die zeit, die dein signal von z.b. deinem mikro braucht, bis es durch den AD [g=60]wandler[/g] gerattert ist und dein sequenzer aufzeichnet.

ausgangslatenz: deine audiospuren im sequenzer benötigen durch die drauf geladenen effekte rechenzeit deines PCs und zusätzlich noch den weg durch den DA [g=60]wandler[/g]...

Wenn man die Effekt weglaesst (und die muss man weglassen wenn man korrekt rechnen soll) ist der Weg exakt der Gleiche.

Von daher muesste es auch eine gleiche [g=5]Latenz[/g] sein.
 
t0nno schrieb:
Wieso ist Eingangslatenz != Ausgangslatenz?
Beides hat doch die selbe Puffergröße,

Und was definiert eigentlich die Eingangs-/Ausgangslatenz?

Das ist nicht dasselbe.
Wenn [g=5]Latenz[/g] verursachende Plugins,
wie z.B. ein Faltungshall verwendet werden,
entstehen vollkommen andere [g=5]Latenz[/g]-Verhältnisse.

Aber ohne zusätzliche Berechnungen usw. sollte die
[g=5]Latenz[/g] in beiden Richtungen gleich sein.

(Siehe Wolfgang)
 
Von daher muesste es auch eine gleiche [g=5]Latenz[/g] sein.

Und genau deswegen wundert sich ja der Thread-Ersteller, warum das in [g=539]Cubase[/g] (scheinbar?) nicht so ist.

Wenn ich z.B. in [g=539]Cubase[/g] ohne ein projekt geöffnet zu haben (es sind also keinerlei Pluginlatenzen auszugleichen) die Ein- und AUsgangslatenz meines [g=12]Asio[/g]-Treibers auf 32 Samples setze, sollte ja für Ein- und Ausgangslatenz der gleiche Wert von knapp einer msec angezeigt werden.
Als Eingangslatenz wird aber angezeigt: 3.628 msec
und als Ausgangslatenz 4.354 msec.

(In anderen Hosts wie z.B. FL Studio wird die [g=5]Latenz[/g] aber korrekt angezeigt.)

Für mich wären zwei Erklärungen denkbar:
1. [g=539]Cubase[/g] berechnet die Anzeigewerte für die Latenzen falsch. (kann ich nicht so ganz glauben, die Formel ist ziemlich einfach...)

2. [g=539]Cubase[/g] verwendet zur internen Verabeitung von Ein- und Ausgabe zusätzliche eigene (unterschiedlich grosse) Buffer sodass die [g=5]Latenz[/g] unterschiedlich sind und deutlich grösser als die reine ASIO-Buffer [g=5]Latenz[/g].

cheers,
Thomas
 
2. [g=539]Cubase[/g] verwendet zur internen Verabeitung von Ein- und Ausgabe zusätzliche eigene (unterschiedlich grosse) Buffer sodass die [g=5]Latenz[/g] unterschiedlich sind und deutlich grösser als die reine ASIO-Buffer [g=5]Latenz[/g]
Das ist m.E. dummes Zeug.

Bei meiner RME DIGI 9636 zeigt [g=539]Cubase[/g] für [g=12]ASIO[/g] Ein- und Ausgangslatenz genau die Werte in ms an, welche rechnerisch zur bei der RME gewählten Buffersize passen.

...und deutlich grösser als die reine [g=12]ASIO[/g]-Buffer [g=5]Latenz[/g]
Nein, da ist gar nichts größer als es rechnerisch sein soll.

Bei meiner Terratec EWS88 D zeigt [g=539]Cubase[/g] dagegen eine etwas größere Ein- als Ausgangslatenz an. Nach dem oben genannten c't-Artikel ist mir das aber völlig wurscht (bei so kleinen Differenzen).

Da man die EWS88 D aber in der Praxis klanglich und timingmäßig nicht von der RME unterscheiden kann ist es völlig Wurscht ist, welche dieser beiden Karten ich gerade benutze, da ja beide perfekt laufen.

Gruß
Werner
 
Das ist m.E. dummes Zeug.

Das war keine Behauptung, sondern eine mögliche Erklärung.
Du hast leider die Aussage nicht widerlegt und auch keine bessere Erklärung gebracht, sondern meine Aussage nur als "dummes Zeug" abqualifiziert.

Nein, da ist gar nichts größer als es rechnerisch sein soll.
32 Samples bei 44.1 KHz ergibt eine [g=12]Asio[/g] Buffer [g=5]Latenz[/g] von ca 0.726 msec.

Cubsase zeigt aber Werte von über 3 bzw 4 msec an. Das ist deutlich grösser als der rechnerische Wert!

Bei meiner Terratec EWS88 D zeigt [g=539]Cubase[/g] dagegen eine etwas größere Ein- als Ausgangslatenz an.

Darum geht es doch hier genau: warum wird für Ein- und Ausgangslatenz etwas anderes angezeigt, wo doch im [g=12]ASIO[/g] Treiber die Buffer jeweils gleich gross sind?


Nach dem oben genannten c't-Artikel ist mir das aber völlig wurscht (bei so kleinen Differenzen).
Ja mag sein, dass es für viele praktische Recording Anwendungen egal ist.

Es ging aber doch in diesem Thread darum zu verstehen, warum das von Tonno beschriebene Phänomen existiert.
 
ich hatte mit nem alesis IO2 mal 5ms in und 40ms out ... das war krass ;)
 
so mal meine erfahrungen: als schmunzelstory

sie ist nicht gleich warum .

was ist zu berücksichtigen :

step1 die hardware:

was spielt die hauptrolle ?
die soundkarten.
es gibt 2 Grundarten von soundkarten die mit firmware, also der [g=12]asio[/g] treiber wird in die soundkarte geladen.
maudio zB :solche soundkarten sind von sich aus meist dynamisch, d.h. man kann da tatsächlich schon in der initalisierung verschiedene werte haben.
die buffers sind im pc meist.
macht dann der sequenzer in [g=539]cubase[/g] zb [g=12]asio[/g] buffer ist nicht gleich wird dann initalisiert und ausgeglichen.

andere soundkarten
haben hardware [g=12]asio[/g] d.h das ganze [g=12]asio[/g] mit dem buffer ist auf der soundkarte und nicht dynamisch, also hat immer den gleichen festen wert.
da gibts den netten button im seq direct [g=12]asio[/g] verwenden.

der buffer ist also auschlaggebend fuer die [g=5]latenz[/g], was wir ja alle schon gewusst haben.

aber son pc hat noch mehr buffer die eine rolle spielen.

das sind buffer auf schnittstellen, für firewire zB, für den chipsatz.
die sind im günstigsten fall gleich.

so machen wir uns mal auf den weg als auto über die AD/DA [g=60]wandler[/g].

ein buffer ist wie ein anstieg je grösser desto länger braucht das auto ans ziel zu kommen,
wenns mit konstanten sampeln faehrt.
also nen [g=12]asio[/g] direct antrieb hat.müsst es ja gleich schnell sein.

so jetz fahr ich den sound zum ohr war einfach, bloss am schluss krieg ich immer noch
sone fette extra steigung 2,8 ms vom seq aufgebrummt.
musst den sequenzer fragen in unserem fall [g=539]cubase[/g].

hey was ist da los ich koennte schneller fahren warum krieg ich die rote karte zum schluss ?
du meinst wohl du bist hier auf der rennpiste ganz alleine,
klar dacht ich immer.

falsch gedacht da faehrt noch einer mit, und der ist immer ungefähr 2.8ms schnell und darum musst da auf den warten damit ihr gleichzeitig ins ziel kommt.

wie heisst den der ander fahrer ?
Mr. [g=32]Midi[/g] ich bin immer 2.8 schnell aber du musst warten....

immer ja immer, sonst verhaut dich der user am pc !
der will das so.(zeitgleiches ereigniss [g=32]midi[/g] und audio !)
hier ist zu unterscheiden kommt das [g=32]midi[/g] vom keyboard, also fester [g=32]midi[/g] buffer berücksichtigen.
oder ist das [g=32]midi[/g] im seq. also kein buffer ...machen wir mal dynamischen latenzausgleich.

darum sind die werte nie gleich.

summasumarium:
die strecke rein ist im besten fall statisch....[g=32]midi[/g] und audio
und der weg raus immer audio dynamisch gebuffert.... muss wegen vsts so sein.

so ist das richtig !

anekdote:
a)sequenzer wie [g=539]cubase[/g] berücksichtigen die [g=32]midi[/g] buffer einrechnung,
b)andere sequenzer machen nur audio buffer rechnung,
C)und die ganz miese lesen nur die buffereinstellung der soundkarte aus, womit sie im idealfall bei directasio karten fast richtig liegen.
wer jetzt meint b und c sind die besseren werte und hat damit den besseren sequenzer,
falsch.
nur a ist richtig weil [g=32]midi[/g] muss mitbrücksichtigt werden in der latenzformel.

warum wissen die fachzeitschriften eigentlich sowas nicht, ja sind auch manchmal nur betriebsblind.
wenn man nur audio analysiert rechnet [g=539]cubase[/g] falsch, klar wir wissen jetze warum.

LG Frank
 
Hallo Frank,

also wenn ich Deine Story richtig verstehe sagst Du folgendes:

1. Der Grund für unterschiedliche Werte für Eingangs- und ausgangslatenz liegt an den [g=12]ASIO[/g] Treibern der Soundkarte, die unterschiedlich Grosse Buffer für In und Out nutzen.

2. Der Grund warum [g=539]Cubase[/g] auf die eigentliche [g=12]ASIO[/g] [g=5]Latenz[/g] noch mal selbst etwas "aufschlägt" liegt am Ausgleich der Midilatenz innerhalb von [g=539]Cubase[/g].

Richtig verstanden?
Wenn ja, kannst Du das irgendwie belegen? So etwas müsste ja irgendwo dokumentiert sein?!
Meine bisherigen Messungen mit Soundkarten (M-Audio und Echo Audiofire) unter Hosts wie FL STudio waren eigentlich die, dass die [g=32]midi[/g] [g=5]Latenz[/g] exakt der Asio [g=5]Latenz[/g] entspricht.

Evtl. Verhält sich [g=539]Cubase[/g] ja bei der Verarbeitung von [g=12]ASIO[/g] + [g=32]Midi[/g] anders? Aber das müsste doch irgendwo im detail erklärt sein?!

Gruss,
Thomas
 
Ich habe mal gelesen, daß ein [g=12]ASIO[/g] Treiber grundsätzlich einen Buffer für eingehende und zwei Buffer für ausgehende Signale benötigt. Das sind [g=12]ASIO[/g]-Spezifikationen, die sich nicht umgehen lassen.

Das würde bedeuten, daß die Ausgangslatenz grundsätzlich doppelt so hoch ist, wie die Eingangslatenz.

Es kommen aber noch die (unterschiedlichen) Zeiten für die Wandlung hinzu (A/D und D/A), die durch Oversampling und digitale [g=43]Filter[/g] entstehen.

RME schreibt dazu im Handbuch des Fireface 400 folgendes:

Während man die Verzögerung der digitalen Schnittstellen relativ vergessen kann, ist bei Nutzung der analogen Ein- und Ausgänge eine nicht unerhebliche Verzögerung vorhanden. Moderne Chips arbeiten mit 64- oder 128-facher Überabtastung und digitalen Filtern, um die fehlerbehafteten analogen [g=43]Filter[/g] möglichst weit aus dem hörbaren Frequenzbereich zu halten.

Dabei entsteht eine Verzögerung von typisch einer Millisekunde. Ein Abspielen und Aufnehmen einer Spur über DA und AD (Loopback) führt so zu einem Offset der neuen Spur von circa 2 ms.

Die genauen Verzögerungen beim Fireface 400 sind:

AD (44,1Khz) = 0,98 ms
DA (44,1 Khz) = 0,63 ms

Wenn ich diese Überlegungen nun auf mein System übertrage, sieht das wie folgt aus:

Eingestellte Buffergröße: 64 Samples

Entspricht (bei 44,1 Khz): ca. 1,45 ms [g=5]Latenz[/g]

Somit wäre die Eingangslatenz: 1,45 ms (einfache Bufferlatenz) + 0,98 ms (AD Wandlerlatenz) = 2,43 ms

und die Ausgangslatenz: 1,45 ms x 2 (doppelte Bufferlatenz) + 0,68 (DA Wandlerlatenz) = 3,58 ms

Ich habe die genauen Latenzwerte gerade nicht im Kopf, die ich in [g=539]Cubase[/g] angezeigt bekomme, aber ich bin mir relativ sicher, daß das (bis auf zwei Stellen hinterm Komma) ziemlich genau hinkommt.

Demnach zeigt [g=539]Cubase[/g] hier genau das an, was ihm durch das [g=12]ASIO[/g]-Protokoll und die Hardware an Latenzzeiten vorgegeben wird.

Vielleicht hilft das dem Threadersteller ja weiter. ;)
 
Dann frage ich mich, warum mein [g=539]Cubase[/g] SX3 bei meiner RME DIGI 9636 (RME-Werbespruch: "[g=12]ASIO[/g] in Hardware gegossen") auf die 1/1000 ms genau exakt die Ein- und Ausgangslatenz anzeigt, die sich rechnerisch für 48 kHz und 256 Samples/Buffer ergeben, nämlich 5,333 ms (siehe Bild).

Auch bei 44,1 kHz und 256 Samples/Buffer werden höchst präzise 5,805 ms angezeigt. Diese Genauigkeit der angezeigten Latenzzeiten bleibt dabei bis zu den kleinstmöglichen 64 Samples/Buffer erhalten, wo [g=539]Cubase[/g] bei ebenfalls 44,1 kHz exakt die theoretischen 1,451 ms anzeigt (auch wenn die auf meinem betagten Single-Core P4 3 GHz praktisch nicht realisierbar sind).

@ Chaos5150:
Das ist OHNE doppelte Ausgangbufferlatenz gerechnet.

@thma:
Zumindest bei meiner DIGI 9636 ist tatsächlich nichts größer als es rechnerisch sein sollte, und zwar auf eine 1/1000 ms genau.

@Frank6502:
OK, beim Einspielen von The Grand 2 muß ich noch zusätzlich ~ 1ms für die [g=32]MIDI[/g]-Ports meiner EWS88 D (nachgemessen mit [g=32]MIDI[/g]-Test) bei der Eingangslatenz dazuaddieren.

Und was nun???
Ich vermute mal, daß das technische Design der DIGI 9636 sehr gut ist, und die hat ja auch interne FIFO-Buffer für schnelle PCI-Transfers ohne CPU-Belastung.
Zudem ist sie als busmasterfähige PCI-Karte hardwaremäßig wesentlich näher an die CPU angebunden als USB- oder FW-Karten, bei denen ja noch zwei zusätzliche USB bzw. FW Controller-Chips bis zum Soundkarten-Chip dazwischenliegen.
Außerdem sind die Busse USB und FW für den gleichzeitigen Anschluß mehrerer Geräte an einem Root-Hub konzipiert und optimiert. Der dafür nötige Protocoll-Overhead (zusätzlich zu den übertragenen Nutzdaten) könnte m.E. durchaus der Grund sein, warum bei USB- und FW-Soundkarten meines Wissens die praktische Ein- und Ausgangslatenz immer größer ist als der theoretische Wert.

Fazit:
1. Leider bleibt nun aber immer noch die Frage offen, wie [g=539]Cubase[/g] die angezeigten Ein- und Ausgangslatenzen ermittelt :-(
2. Am Beispiel meiner RME DIGI 9636 konnte ich hier aber immerhin zeigen, daß grundsätzlich gesehen durchaus die kleinstmöglichen theoretischen Werte erreicht werden können.
3. PCI bzw. PCIx Soundkarten sind anscheinend nicht umsonst schon lange bei vielen Leuten beliebt, die besonderen Wert auf minimale Latenzzeiten legen.

Gruß
Werner
 

Anhänge

  • cubase_latenz.gif
    cubase_latenz.gif
    3,5 KB · Aufrufe: 159
Hallo zusammen,

Ich habe ein wenig weiter geforscht.
Ich habe jeweils im [g=12]Asio[/g] Treiber verschiedene Buffergrössen eingestellt und die von [g=539]Cubase[/g] angezeigten Zeiten ebenfalls in Samples umgerechnet.

Hier die Ergebnisse für meine Echo Audiofire12 (Firewire Karte):

[g=12]Asio[/g] IN OUT
64 192 256
128 256 384
256 384 640
512 640 1152

Aus diesen Werten ergeben sich folgenden Formel für In und Out [g=5]Latenz[/g] (in Samples bei einem [g=12]Asio[/g]-Buffer der Grösse N)
[g=5]Latenz[/g] In = N +128
[g=5]Latenz[/g] out = 2*N +128

Die 2*N passen zu der Aussage von Chaos5150, dass für den Output die doppelte Buffergrösse benötigt wird. (Zumindest für Werners Karte scheint das aber nicht zu gelten!)

Dann wäre jetzt noch zuklären, wie sich die zusätzlichen 128 Samples Versatz erklären lassen.
 
@werner

diese rme sind genau die karten mit [g=12]asio[/g] auf hardware und der sogenannte ausnahmefall,

für direct [g=12]asio[/g] in hardware gegossen
soll heissen feste puffer keine firmware,
ich wollte keine schleichwerbung machen.

und genau nur in deiner konstalation ist ja auch kein zusätzlicher buffer drin,

soll heissen keine firewirekarte mit buffern....

wenn du mal altes [g=32]midi[/g] bedienst, also kein usb.

kommst du mit 1ms nicht hin,
weil das [g=32]midi[/g] hat ne höhere [g=5]latenz[/g] , also keine sternverdrahtung...

mit [g=32]midi[/g] thru und midisoftthru...
da sind auch puffer drin.

da nimmt man nen wert von 3ms der ist ja immer noch echtzeit
und alle outboard midihardware hat wenigstens ne grosse chance völlig syncron zu sein.

das war eines der ersten probleme die die steinis lösen mussten,
damals gabs nur [g=32]midi[/g] und je mehr desto unsyncroner, also schwamiges timing.

hat sich ja alles geaendert seit damals, und trotzdem muss nen moderner seq auch altem [g=32]midi[/g] equip gerecht werden.

-------------------------------------------------------------------------------------------------------------
cpu leistung
und wie du schon sagst wenn du das zu klein schraubst kommt die cpu nicht mehr mit.
was sinnlos ist da 3ms immer noch wie echtzeit ist.
alle werte bis 256 sind für mich spielbar,
256 verhaelt sich wie nen brass instrument mit kurze lautlose attack,
für anfänger schwierig zu spielen.
in 64sampels musst du auch üben nen brassound reinzuspielen.

mein lieblings [g=5]latenz[/g] ist 128,
da brauch ich bis zum ende des projekts nicht wechseln,
und mein hallplug soundet auch amtlich damit.

für usb
wichtig ist das der wert konstant ist was bei karten mit usb und firmware schonmal sehr schlecht ist.
schlechte [g=426]bandbreite[/g], falsches protokoll für audio und zuviele usb peripherie.
da kannste mit 160 oder 256 zufrieden nach hause gehn.
kann man auch noch mit arbeiten obwohl weniger live tauglich mit outboard [g=32]midi[/g],
zum jammen.

für firewire
ist viel besser , richtiges protokoll, gute [g=426]bandbreite[/g] und maximal ein extrabuffer im firewire chipsatz.
landest dann knapp unter 3ms.

LG Frank
 

Neue Antworten


Oft gelesene Themen

Zurück
Oben