Audio Latenz

  • Audio Latenz

    Bevor ich ewig suche, vielleicht kann mir einfach jemand eine Größenordnung (reicht mich schon) nennen, wie gross bei Consumer-Hardware und bei Profi-Hardware so etwa die Latenz zwischen einem Lautsprecher und einem Micro am gleichen Rechner ist. Also wenn ich ein Mikro direkt an mein Lautsprecher halte, "optimalen" Code verwende, mit was für einer Verzögerung kann ich da rechnen, mit der ich das Signal wieder aufnehme? Ich würde auf Millisekunden tippen, passt das?
    ♥C++

  • Was genau definierst du denn als Hardware ?

    Wenn ich ein Micro/Vorverstärker/Endstufe/Box nehme habe ich sicherlich keine messbare Verzögerung :)

    Der Rest ist ja reine Rechenpower, bzw was mit den Daten überhaupt gemacht wird. Auf meinem MacBookPro kann ich z.B. ohne Zusatzhardware locker auf 100-200ms kommen wenn ich entsprechend hochwertige Sounds (z.B. eine wirklich gutes Digital-Piano) haben möchte. Wenn du einfach nur einen Sinuston abspielst wirst Du sicher unter 10ms liegen.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • CoreAudio selbst ist komprisslos auf gernige Latenzzeit optimiert. Die Latenz hängt hauptsächlich von der Puffergröße und von Peripherielatenzen ab (z.B. hast Du eine zusätzliche Latenz von einigen ms, wen Du ein externes USB-Audiointerace verwendest). Die Puffergröße ist wählbar, es ist also immer Tradeoff zwischen Stabilität des Streams und geringer Latenz. Im besten Fall sollte es aber im einstelligen ms-Bereich sein.

    Ach ja, und intern ist alles mit Timestamps versehen, manchmal kann man also nachträglich alles wieder zusammenfummeln.
    Multigrad - 360°-Produktfotografie für den Mac

  • Thallius schrieb:

    Der Rest ist ja reine Rechenpower, bzw was mit den Daten überhaupt gemacht wird. Auf meinem MacBookPro kann ich z.B. ohne Zusatzhardware locker auf 100-200ms kommen wenn ich entsprechend hochwertige Sounds (z.B. eine wirklich gutes Digital-Piano) haben möchte. Wenn du einfach nur einen Sinuston abspielst wirst Du sicher unter 10ms liegen.
    Ähm, also "wirklich gutes Digital-Piano" und eine Latenz im Zehntelsekunden-Bereich schließen sich gegenseitig aus. Das ist völlig unspielbar. Der Rechenaufwand der Klangerzeugung hat mit der Latenz rein gar nichts zu tun. Da ist nur fraglich, ob der Puffer rechtzeitig fertiggerechnet ist, sonst kommt Murks aus den Boxen. Die Latenz wird letztlich wie schon erwähnt hauptsächlich vom Programmierer durch die Puffergröße festgelegt (zzgl. der Hardwarelatenz, üblich einige ms).

    Der Vollständigkeit halber: eventuell kommt zu der durch die Wandlung verursachten Latenz noch eine weitere hinzu, die durch die verwendeten Algorithmen verursacht wird. Klassiker sind hier Algorithmen, die mit Lookahead arbeiten (der Algo kann leider nicht in die Zukunft sehen, stattdessen behilft er sich damit, das Ausgangssignal zu verzögern) oder wo Blockverarbeitung eine Rolle spielt (FFT).

  • hugoderwolf schrieb:

    Ähm, also "wirklich gutes Digital-Piano" und eine Latenz im Zehntelsekunden-Bereich schließen sich gegenseitig aus. Das ist völlig unspielbar. Der Rechenaufwand der Klangerzeugung hat mit der Latenz rein gar nichts zu tun. Da ist nur fraglich, ob der Puffer rechtzeitig fertiggerechnet ist, sonst kommt Murks aus den Boxen. Die Latenz wird letztlich wie schon erwähnt hauptsächlich vom Programmierer durch die Puffergröße festgelegt (zzgl. der Hardwarelatenz, üblich einige ms).


    Eben darum habe ich es erwähnt. Auf meinem MacBook ist ein gutes EPiano unspielbar.

    Und das "nur" der Puffer befüllt werden muss stimmt nur solange wie Du immer einen Ton spielst. Was ist aber wenn ich mit gehaltenem Sustain-Pedal alle 81 Tasten meines Pianos anschlage ? Das gibt schon eine gewaltige Rechnerei das alles richtig zu mischen. DA nutzt Dir kein Puffer irgendwas.

    Aber Du hast recht, wenn du die reine Hardware Latenz nehmen willst dann bist du sicher unter 10ms. Das habe ich aber auch geschrieben.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Thallius schrieb:

    Eben darum habe ich es erwähnt. Auf meinem MacBook ist ein gutes EPiano unspielbar.

    Und das "nur" der Puffer befüllt werden muss stimmt nur solange wie Du immer einen Ton spielst. Was ist aber wenn ich mit gehaltenem Sustain-Pedal alle 81 Tasten meines Pianos anschlage ? Das gibt schon eine gewaltige Rechnerei das alles richtig zu mischen. DA nutzt Dir kein Puffer irgendwas.
    Du sitzt einem Irrtum auf. Natürlich gibt das eine gewaltige Rechnerei, das hat aber mit der Latenz null komma null zu tun. Wenn ein Echtzeit-DSP-Algorithmus viel zu tun hat, erhöht sich nicht plötzlich die Latenz, es erhöht sich nur die Gefahr, dass er die Echtzeitbedingungen nicht einhalten kann und der gerade zu berechnende Puffer nicht rechtzeitig fertig wird. Dann kommt der Ton aber trotzdem nicht später, sondern einfach gar nicht (oder kaputt).

    Darf ich fragen, von welchem E-Piano du sprichst? Es gibt nämlich eine ganze Menge Leute, die Live mit Macbooks sehr gute E-Piano-Sounds spielen, und das nicht erst seit gestern. Ich selbst habe das bspw. schon vor 8 Jahren mit 'nem G3 iBook gemacht.

  • Vielen Dank Leute, das war schon genau, was ich wissen wollte.

    Im Prinzip ging es bei mir nur um ein spezielles Problem, wo ich aus der Signallaufzeit etwas messen wollte. Wenn die "normale" Latenz im Millisekunden-Bereich liegt, fällt das aber im konkreten Fall für mich aus. Das ist auch genau das, was ich erwartet hatte - jetzt habe ich noch einmal eine Bestätigung :)

    Ich bin jetzt aber am überlegen, ob ich zumindest die genaue Latenz kennen könnte. Wenn ich also meinen Input-Puffer immer genau nach vielleicht 2ms gefüllt habe, nachdem ich meinen Output-Puffer rausgegeben hab, müsste ich noch einmal umdenken. Mhh. Vielleicht bin ich doch etwas falsch rangegangen?

    Was ich eigentlich will, bzw. die Möglichkeit zumindest betrachten wollte, ist, ob ich minimalste Signallaufzeit-Unterschiede (>>1ms) irgendwie gemessen bekomme. Quasi:
    1. Versuch: Abspielen, aufnehmen, Verzögerung ist Hardware-Latenz + 1ms
    2. Versuch: Abspielen, aufnehmen, Verzögerung ist Hardware-Latenz + 1,01ms
    => Ergebnis 0,01ms Unterschied.
    In Wirklichkeit will ich das gar nicht, ich will nur schlüssig argumentieren, dass soetwas auf Consumer-Hardware extrem schwierig zu bestimmen wäre :)

    Vielleicht hätte ich gleich mal das konkrete Szenario aufführen sollen..naja, danke jedenfalls nochmal! :)
    ♥C++

  • Das geht prinzipiell schon. Die Latenz ist jedenfalls schonmal konstant und dementsprechend messbar.

    Wie klein die Laufzeitunterschiede sein dürfen ist wiederum eine Frage der Signalverarbeitung. Am einfachsten wäre bspw. einen Impuls abzufeuern und dann zu schauen, wann die höchste Pegelspitze wieder am Eingang ankommt. Das ist aber recht ungenau, da der Impuls ja durch Lautsprecher und Mikrofon etwas verformt wird (vereinfacht gesagt), besonders wenn die Teile mies sind.

    Nächste Stufe wäre sowas wie Kreuzkorrelation zwischen Input und Output. Damit kommst du schon auf eine Genauigkeit von etwa einem Sample, was bei 44,1kHz 0,02ms entspräche. Ist auch noch knapp, ne?

    In welchen Größenordnungen befinden sich denn die zu messenden Laufzeitunterschiede? Wenn du wirklich im Subsample-Bereich messen willst, ist wahrscheinlich die Verwendung von eher tieffrequenten Signalen anzuraten, dort könntest du dann die Phasenlaufzeit messen. Geht es denn um direkte Messung von irgendeiner Laufzeit, oder um den Vergleich von Laufzeiten, die mit ein und demselben System gemessen wurden? Bei letzterem kannst du dir nämlich die Plackerei mit dem Latenzausgleich ohnehin sparen.

  • zerm schrieb:

    Was ich eigentlich will, bzw. die Möglichkeit zumindest betrachten wollte, ist, ob ich minimalste Signallaufzeit-Unterschiede (>>1ms) irgendwie gemessen bekomme

    Prinzipiell müsste das gehen, indem Du ein eindeutiges Signal ausgibst, gleichzeitig aufnimmst und die beiden Signale korrelierst (und die akustische Verzögerung zwischen Lautsprecher und Mikrofon abziehst). Wie gesagt, systemintern ist alles sehr genau mit Zeitstempeln versehen, das müsste man rausrechnen können.

    Andererseits kommt es wirklich darauf an, was Du mit "minmalste Laufzeitunterschiede" meinst. Im Bereich von wenigen µS wird's schon alleine wegen des Jitters in den Analogwandlern schwierig. Die sind halt für Frequenzen bis ca. 20 kHz, also 50 µS, ausgelegt.

    Und wenn Du Spezialhardware brauchst, sag' Bescheid.

    Edit: Der Hugo, der war schneller. Und es ist fast das gleiche - rein demokratisch muss es also stimmen :)
    Multigrad - 360°-Produktfotografie für den Mac

  • hugoderwolf schrieb:

    Nächste Stufe wäre sowas wie Kreuzkorrelation zwischen Input und Output. Damit kommst du schon auf eine Genauigkeit von etwa einem Sample, was bei 44,1kHz 0,02ms entspräche. Ist auch noch knapp, ne?

    Ich hab ein ganzes Framework fertig, was das numerisch simuliert (jemand interesse?) :D Da funktioniert das mit Kreuzkorrelation auch super. Die Überlegung war jetzt, wie man das "in echt" machen könnte.
    Das Problem ist ja aber, dass ich Input und Output ja nicht einfach korrellieren kann, weil Puffer, CPU Takt / Interrupts, DAC alles variable(?) Zeit frisst. Mein Output ist zudem ja konstant, ich müsste bei einem Impuls also wirklich nur schauen, wann der in der Aufnahme kommt (kann man ja auch Sub-sample interpolieren, wenn ich einen schönes Signal hab geht das ja ganz gut).

    hugoderwolf schrieb:

    In welchen Größenordnungen befinden sich denn die zu messenden Laufzeitunterschiede? Wenn du wirklich im Subsample-Bereich messen willst, ist wahrscheinlich die Verwendung von eher tieffrequenten Signalen anzuraten, dort könntest du dann die Phasenlaufzeit messen. Geht es denn um direkte Messung von irgendeiner Laufzeit, oder um den Vergleich von Laufzeiten, die mit ein und demselben System gemessen wurden? Bei letzterem kannst du dir nämlich die Plackerei mit dem Latenzausgleich ohnehin sparen.

    Wegen numerischer Simulation habe ich ohnehin nur niederfrequente Signale :) Phasenlaufzeit, soetwas hatte ich überlegt.
    Genaugenommen kann ich ja zwei Messungen durchführen, und zwischen den beiden Messungen eine meinetwegen Kreuzkorrelation errechnen um die Verschiebung zu bestimmen. In der Theorie sollte das ja super klappen, aber ich bin davon ausgegangen, dass 90% der (Phasen-)Verschiebung aufgrund der Hardware und nur 10% aufgrund der "Physik" sein wird, und ich daher nicht viel lerne.

    Praktisch sollten die Laufzeitunterschiede unter 1ms liegen, was das ganze natürlich nicht leichter macht.

    Ist mein letztes Uni-Projekt, was ich grad fertig stelle, ich mach nur noch die Dokumentation rund - oder versuch es. Die genaue Messung wäre wahrscheinlich eine Projekt für sich. Aber für jede Idee bin ich dankbar, kommt dann halt in den "Future Work" teil :)
    Wiegesagt, wenn ich fertig bin teile ich gerne das Zeug. 2D numerische Simulation der Wellengleichung in OpenCL mit absorbierenden Rändern und schnickschnack, anyone?
    ♥C++

  • mattik schrieb:

    Andererseits kommt es wirklich darauf an, was Du mit "minmalste Laufzeitunterschiede" meinst. Im Bereich von wenigen µS wird's schon alleine wegen des Jitters in den Analogwandlern schwierig. Die sind halt für Frequenzen bis ca. 20 kHz, also 50 µS, ausgelegt.
    Jitter hat mit dem Problem wenig bis gar nichts zu tun. Der äußert sich nicht in irgendeiner zeitlichen Ungenauigkeit (die gibt es bei Digitalsignalen eigentlich nicht), sondern in schlechterem Rauschabstand.

    Nochmal zum Thema Laufzeitunterschiede messen: wenn es um den Subsample-Bereich geht wird man auch zunehmend Probleme mit Nachhall bekommen. Auf Grund der Fragestellung gehe ich davon aus, dass die Consumerhardware nicht im schalltoten Raum steht. Und da es ja offenbar eigentlich darum ging, Pessimismus zu begründen, wäre das sicher ein gutes Argument. Je nach Vorgabe wäre es dann nämlich mit einfachen Phasenmessungen nicht getan, sondern es wären noch irgendwelche statistischen Schätzer oder so von Nöten. Der Spaß steigt mit jeder Mikrosekunde geforderter Präzision exponentiell. :D

  • Da warste schneller als ich. Aber sei beruhigt: die Latenz zwischen Output und Input ist immer konstant, du kannst also getrost mehrere Messungen vergleichen, oder zuvor das Ganze kalibrieren (bspw. indem du das Mikro direkt vor dem Lautsprecher positionierst).

    Zusammengefasst kann man sagen, dass die Latenz dein geringstes Problem ist, sondern eher das gute alte reverberant environment, wie der Fachmann sagt. ;)

  • Ah ok. Hätte ich vielleicht doch mal so probieren sollen. Naja, ich hatte ohnehin nicht so lange Kabel wie ich gebraucht hätte. Und mein Mikrophon ist einfach nur Mist ;) Dazu kommt, dass eine praktische Lösung nicht mit einem Rechner allein sondern unabhängiger Quelle und Mikro sinnvoll gewesen wären, und da bekomm ich ja noch mehr probleme... Mhh...

    "reverberant environment", mal nachschauen, danke für den Hinweis!
    ♥C++

  • hugoderwolf schrieb:

    arf ich fragen, von welchem E-Piano du sprichst? Es gibt nämlich eine ganze Menge Leute, die Live mit Macbooks sehr gute E-Piano-Sounds spielen, und das nicht erst seit gestern. Ich selbst habe das bspw. schon vor 8 Jahren mit 'nem G3 iBook gemacht.


    Ich rede vom Steinberg Cubase. Verwende das mal ohne externe Audio-Karte. Das geht nicht wirklich. Klar, wenn ich eine gute Soundkarte anstecke, dann sieht das ganze gleich ganz anders aus. Denn dann habe ich den von Dir angesprochenen guten DSP der mir das alles rechnet. Die interne Karte eines MBP streicht jedenfalls alle Segel.

    und Nein, er macht nicht kaputte Sounds oder bricht an, er spielt das ganze einfach 100-200ms später ab, als man am MIDI-Keyboard die Taste drückt und das macht die Sache sehr unbrauchbar für jeden Musiker.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Thallius schrieb:

    Ich rede vom Steinberg Cubase. Verwende das mal ohne externe Audio-Karte. Das geht nicht wirklich. Klar, wenn ich eine gute Soundkarte anstecke, dann sieht das ganze gleich ganz anders aus. Denn dann habe ich den von Dir angesprochenen guten DSP der mir das alles rechnet. Die interne Karte eines MBP streicht jedenfalls alle Segel.
    Nee, Irrtum! Soundkarten liefern keine zusätzliche DSP-Rechenleistung (abgesehen von Ausnahmen wie ProTools TDM oder Metric Halo, aber auch in dem Fall nur über spezielle Software). Das passiert alles im Rechner, und zwar unabhängig von der CPU-Last. Auch bei Cubase. (Mit DSP habe ich im vorigen Post übrigens keinen speziellen Prozessor gemeint, sondern lediglich einen entsprechenden Algorithmus, der aber ganz normal auf der CPU läuft).

    Thallius schrieb:

    und Nein, er macht nicht kaputte Sounds oder bricht an, er spielt das ganze einfach 100-200ms später ab, als man am MIDI-Keyboard die Taste drückt und das macht die Sache sehr unbrauchbar für jeden Musiker.
    Mit Verlaub, diese Geschichte kommt mir höchst spanisch vor (ich sollte vielleicht dazu sagen, dass ich meinen Lebensunterhalt mit der Entwicklung von solchem Zeugs bestreite). Was du da schilderst hat mit Sicherheit einen anderen Grund (und es gibt da noch eine Vielzahl an Möglichkeiten).