Die 0,045 ms für zwei Samples kann das Teil mit Sicherheit nicht rausmessen
Wieso, es misst doch samplegenau. Die Millisekunden rechnet es ja erst nachher aus. Messtechnich sind die zwei Stellen hinterm Komma, die eher auch angibt, natürlich "verboten genau", weil er ja ein Sample Messungenauigkeit hat. Ok, so gesehen würde der Unterschied wohl in der MEssgenauigkeit untergehen. Bei der analogen Aufnahme können aber eh gewisse ungenauigkeiten auftreten, weil der Wandler nicht so perfekt ist, sprich: Der Impuls sieht nachher etwas anders aus. Die perfekt steile Flanke des Mess-Impulses ist nachher eventuell nicht ganz so steil; auch bei menen manuellen Messung (wo ich per Auge Samples gezählt habe) ist das da nicht immer so samplegenau.
Ich hab übrigens rausgefunden, warum er auch ohne Kabelverbindung etwas gemessen hat: Er schickt das Signal an alle Ausgangskanäle, und empfängt auch von allen Eingängen. Meine Soundkarte hat da einen DSP-Monitoring-Mixer - und dessen Ausgang ist auch ein Aufnahmekanal. SO bestand schon quasi intern dieser INput-Output-Kurzschluss.
Den hab ich dann aber gemutet und nun mal richtig übers analoge Kabel gemessen.
Athlon XP 1600+, 512MB RAM, VIA-KT266A Chipsatz Windows XP SP3
M-Audio Delta 1010 LT mit M-Audio-ASIO-Treiber:
1089 Samples (24,69 ms)
VIA AC' 97 (Onboard-Sound) mit ASIO4ALL:
1055 Samples (23,92 ms)
Leider funktioniert ASIO4ALL mit der 1010LT nicht (also an sich schon, aber bei dem Programm bekomme ich es irgendwie nicht hin.
Bei der Gelegenheit habe ich dann aber auch mal ASIO4ALL und Samplitude (oder die ASIO-Architektur an sich) etwas besser kennen gelernt, weil ich da dann eben auch noch mal solche Testaufnahmen gemacht hat. Die Latenzkorrektur arbeitet nicht perfekt, es ist immer noch eine Verschiebung da. Aber diese entspricht (was ja zu erwarten war) in etwa zusätlichen Latenz, die mir auch diese Latenzmesssoftware anzeigt (also als Differenz zwischen dem ASIO-Puffer und der tatsächlichen Latenz). Samplitude gleicht halt nur den Wert aus, der ihm bekannt ist (und das ist zunächst mal der eingestellte ASIO-Puffer). Allerdings hat ein ASIO-Treiber wohl die Möglichkeit, einen anderen Wert zu melden. Und so weiß ich jetzt auch, wozu es den Punkt "Latenzausgleich" beim ASIO4ALL-Treiber gibt. Wenn man dort was einstellt, dann ändert sich nicht die tatsächliche Latenz, aber Samplitude wird gesagt, dass die Latenz entsprechend höher sei. Und das wiederum macht dann auch einen passenden Ausgleich. Es zeigt in den Einstellungen auch die In- und OutLatenzen an, um die es ausgleicht. Wenn ich in ASIO4ALL also z.B. 512 Samples Puffer einstellte, zusätzlich aber unter "Latenzausgleich" 16 Samples für Eingang und 32 Samples für den Ausgang, dann sagt Samplitude, dass man 528 Samples Input, und 544 Samples Outputlatenz hat. Und diese Werte nimmt es dann wohl für den Latenzausgleich.
Beim M-Audio-ASIO-Treiber habe ich nichtz die Möglichkeit manuell eine solche zusätzliche Latenzinfo anzugeben. Stattdessen hat da wohl M-Audio feste Werte eingegeben. Denn wenn ich mit der M-Audio arbeite, dann gibt Samplitude 542 Input und 544 Output an, zusammen also 1086. Und das ist ja in der Tat dann in etwa der gemessen Wert, also gibt M-Audio da was realistisches an. Allerdings wundern mich die 30 Samples zusätzlicher Inputlatenz. 32 wäre irgendwie logischer gewesen, ist ja beim Output auch so (und ASIO4ALL hat standardmäßig auch 32 in + 32 out eingestellt, ist wohl in der Praxis ein geläufiger Wert), und es hätte eher der Realität entsprochen.
Wie auch immer - es würde mich echt interessieren, was so bei anderen rauskommt. Und was dem gegenüber eine Audiosoftware anzeigt. Also ob das wirklich stark abweicht, so dass dann die Latenzkorrektur nicht richtig funktionieren kann. Weil irgendwie tauchen hier ja doch gelegentlich Fälle auf, wo sich jemand beklagt, dass Spuren nicht synchron ueinander sind. Eigentlich wäre es dann ja durchaus sinnvoll, wenn der Hersteller für seinen Treiber die Möglichekit gibt, diese zusätzlche Latenz manuell einzustellen, so wie es bei ASIO4ALL der Fall ist. Und dazu könnte er dann ein Messprogramm liefern (oder in die Treibersoftware integrieren; dann könnte das sogar automatisch gehen). Dann kann man einfach eben messen, die Abweichung zwischen thereotischem und praktischem Wert also zusätzliche Latenz einstellen, die Aufnahmesoftware bekommt einen korrekten Wert und kann einen optimalen Latenzausgleich machen. OK, so ganz würde das doch nicht gehen, weil man bei der MEssmethode ja nur die Gesamtlatenz misst, und nur Vermuten kann, dass diese sich gleichmäßig auf Input und Outputlatenz aufteilt. Hmm...
Audacity macht die "manuell" (durch verschieben der Spur), also da kann man tatsächlich ablesen, wie stark die Verschiebung zwischen den Spuren ist. Aber Audacity arbeitet ohne ASIO-Treiber, die Info über die dort auftretende Latenz bringt mir also nicht viel.
Und mit einem realistischen Wert.
