Low Latency ist Low Latency?

  • Ersteller David86Thomsen
  • Erstellt am
wie oben - nur diesmal in Cubase als Host.

alle Einstellung gleich. In Cubase lässt sich die Kernanzshl in kontakt auch anpassen. War ist aber weiterhin 12 Kerne.

kann man das global in Cubase auch einstellen? Ich nutze 9.5.40. ich habe den Haken bei „Multiprocessing“ gesetzt. Ist das die einzige Einstellubg derart?
Wenn in Cubase Multicoreprocessing aktiv ist, kannst Du in Kontakt die Funktion ausschalten.
Cubase verwaltet dann das MCP für Kontakt.
Wenn Du Kontakt Standalone nutzt, muss es wohl an, es sei denn deine Maschine kann das irgendwie verwalten.
 
wie oben - nur diesmal in Cubase als Host.

alle Einstellung gleich. In Cubase lässt sich die Kernanzshl in kontakt auch anpassen. War ist aber weiterhin 12 Kerne.

kann man das global in Cubase auch einstellen? Ich nutze 9.5.40. ich habe den Haken bei „Multiprocessing“ gesetzt. Ist das die einzige Einstellubg derart?
Wenn in Cubase Multicoreprocessing aktiv ist, kannst Du in Kontakt die Funktion ausschalten.
Cubase verwaltet dann das MCP für Kontakt.
Wenn Du Kontakt Standalone nutzt, muss es wohl an, es sei denn deine Maschine kann das irgendwie verwalten.
Okay! Versuche ich auch nochmal.
 
Wie gerade beschrieben habe ich nun wieder alles in Maschine als Host. Obwohl die Auslastung der CPU okay zu sein scheint, kommt es zu „knackern“.

@Graham: Hab jetzt auch auf 44.1 kHz gewechselt.
 
@Entone :

Auf dem ersten Bild ist noch alles grün. Der Ton lief mit einigen Knacksen „normal“ durch

dann hab ich das Fenster gewechselt. Der Rechner hat einen regelrechten Schüttelkrampf bekommen. Da hab ich das zweite Bild gemacht.

kann das an der Grafkikarte liegen?

kann es auch zu knacksern kommen, wenn im LatMon noch alles grün ist?

btw: nices tool
 

Anhänge

  • A36D9A91-0C96-44DB-8786-858840A37CB2.jpeg
    A36D9A91-0C96-44DB-8786-858840A37CB2.jpeg
    4,6 MB · Aufrufe: 267
  • 3D931585-3E00-405C-BB64-E8E21B9AB904.jpeg
    3D931585-3E00-405C-BB64-E8E21B9AB904.jpeg
    4,5 MB · Aufrufe: 263
Zuletzt bearbeitet:
@Entone :

Auf dem ersten ist noch alles grün. Der Ton lief mit einigen Knacksen normal durch

dann hab ich das Fenster gewechselt. Der Rechner hat einen regelrechten Schüttelkrampf bekommen. Da hab ich das zweite Bild gemacht.

kann das an der Grafkikarte liegen?

kann es auch zu knacksern kommen, wenn im LatMon noch alles grün ist?

btw: nices tool
Schau mal hier unter Punkt 3.2. Da werden die Werte erläutert.
https://support.native-instruments....-Optimierungs-Tipps-für-die-Audioverarbeitung
 
Aber hängen diese Latenzen mit den des Interface überhaupt zusammen? Gibt es zwei völlig unterschiedliche Latenzen?
Latenz ist immer eine Summe von einzelnen Latenzen.

LatencyChain_12-30-13_RR02.jpg

Was aus der Grafik nicht hervorgeht ist die Latenz, die von einzelnen Plugins fabriziert wird. Auf die hat man als normal-sterblicher anwender noch am ehesten einfluss... FabEQ erzeugt im höchsten Phaselinear mode >1-2 sek latenz. (Bei mir zumindest) Einfluss aber nur insoweit, dass man die plugins eben nicht verwendet :p

Auf die Treiberlatenzen hat man (von den konfigurierbaren puffern abgesehen) recht wenig einfluss.

Was mich extrem nervt ist, dass es zumindest bei ableton keine (automatische/brauchbare) latenzkompensation gibt, was den midi ausgang in relation zum audio ausgang angeht. Zwar hat man Trackdelays, die funktionieren bei midi spuren aber auch nur in gewissen grenzen und das reicht irgendwann im verlauf der produktion bei mir nicht mehr aus. Der MidiTrack.-Delay begrenzt irgendwo bei 100-200 ms, höhere werte haben keinen effekt mehr. Eigentlich könnte eine Software "einfach" die resultierende Latenz am ende der Audio-Kette hernehmen und als delay der midi spuren aufrechnen. Ohne dass der Anwender da irgendwas grossartig justieren muss. Irgendwo in v9 hat ableton einiges gerade gezogen was die daw internen latenzen angeht, Leider hamse das bei der midi ausgabe nicht berücksichtigt.. :(
 
@Entone :

Auf dem ersten Bild ist noch alles grün. Der Ton lief mit einigen Knacksen „normal“ durch

dann hab ich das Fenster gewechselt. Der Rechner hat einen regelrechten Schüttelkrampf bekommen. Da hab ich das zweite Bild gemacht.

kann das an der Grafkikarte liegen?

kann es auch zu knacksern kommen, wenn im LatMon noch alles grün ist?

btw: nices tool
Klick Dich oben durch Processes und Drivers und schau, wer der Störenfried ist.
 
Hast Du mal diese Latency Check Programme ausgeführt, die ich oben verlinkt habe? Da sollte Dir dann angezeiugt werden, was die Latenz versemmelt.
Läuft. Sieht aber unauffällig aus. Konstant bei 1000mys.
Lass Dir in den Latency Check Programmen anzeigen, welche Programme die größten Latenzen verursachen.

Der Latency Check bringt in der Regel nur selten Ergebnisse , wo irgendwelche Programme zu hohe Latenzen dabei sind, war dir das nicht klar @Entone? Hast du mal geschaut ob es die Festplatte ist? Ich habe schon erlebt, dass selbst eine SSD Platte im Leerlauf Peaks erzeugt und das im leeren Cubase Projekt. Sogar haben Leute im leeren Projekt immer wieder ein Plugin im Control Room von Cubase, und der Control Room wird aktiviert im leeren Projekt, da kannst du lange nach hohen Latenzen suchen.
 
Zuletzt bearbeitet:
Hallo Folks!

Ich mache schon lange mukke am Computer. Aber um ehrlich zu sein: es gibt immer noch 1 Mio Sachen die ich nicht 100%ig durchblicke!

Latenzen

Viele Hersteller (fast alle?) werben mit irgendwelchen fantastischen Angaben zu Latenzen.

Ich nutze aktuell ein Win10 System mit 32gb RAM und i9700 CPU. Als Interface verwende ich ein UAD Apollo Twin Duo USB.

Ich hätte jetzt gedacht - das sollte eigentlich allen Ansprüchen reichen - wenn ich nicht ein VSTi-Orchester abfeuern will.

Aaaber.... gerade unter NI Maschine ist nach 5 Instanzen Kontakt Schluss. Entweder fängt das große Knacken an (CPU Last zu hoch?) oder ich muss derart an der Interface-Latenz (rauf auf 512 Samples) drehen, dass ein sinnvolles Nutzen von MIDI-Instrumenten nicht möglich ist.

So richtig toll ist das irgendwie nicht.

Aber hängen diese Latenzen mit den des Interface überhaupt zusammen? Gibt es zwei völlig unterschiedliche Latenzen?

ich hatte die Suchfunktion des Forums bereits bemüht - dadurch bin ich wenn überhaupt nur unsicherer geworden...

Kann mir das einer erklären? Und: welches Interface ist zum nutzen von MIDI/VSTi am besten und bietet das direkteste und unverfälschteste Spielerlebnis? (Im sinne von: geringste Verzögerungen von Tastendruck bis Audiowiedergabe und Noten-Aufzeichnung?)

ich danke euch!

David

Windows 10 latency | NI Community Forum (native-instruments.com)

Ist in englisch , kannst auch mal drüber fliegen, könnte auch am Netzwerk Adapter liegen, ggf Speedstep im Bios mal deaktivieren falls aktiv. Der PC läuft hoffentlich NICHT im Energie-Spar Modus, gelle?
 
Der Latency Check bringt in der Regel nur selten Ergebnisse , wo irgendwelche Programme zu hohe Latenzen dabei sind, war dir das nicht klar @Entone?
Kannst Du auch einfach mal nix schreiben, wenn Du keine Ahnung hast?!?
 
Der Latency Check bringt in der Regel nur selten Ergebnisse , wo irgendwelche Programme zu hohe Latenzen dabei sind, war dir das nicht klar @Entone?
Kannst Du auch einfach mal nix schreiben, wenn Du keine Ahnung hast?!?

Meine Güte woher oder wo oder was hast du denn Ahnung überhaupt? Geh doch mal systematisch vor, anstatt irgendwo reinzuspringen und den DPC Latency Joker zu ziehen.
 
Wie gerade beschrieben habe ich nun wieder alles in Maschine als Host. Obwohl die Auslastung der CPU okay zu sein scheint, kommt es zu „knackern“.

@Graham: Hab jetzt auch auf 44.1 kHz gewechselt.

Könnte durchaus sein , mittlerweile habe Grafikarten einen Low Latency Modus, der heisst dann teilweise aber anders, kann auch Performance Modus heissen. Und bitte, aktiviere im Cubase nicht das Steinberg-eigene Energie Profil , das betreibt nämlich Core Parking, also werden CPU Kerne geparkt und das mag so manche DAW und so manches Plugin leider gar nicht. Sollten besser alle Kerne aktiv sein, vor allem wenn Kontakt im Multicore Modus läuft ist Core-Parking nicht fein.
 
Der Latency Checker misst soweit ich weiss nur die Treiber und interrupt latenzen. Wenn irgendwas in der Applikation schiefläuft zeigt er das nicht an....
 
Der Latency Checker misst soweit ich weiss nur die Treiber und interrupt latenzen. Wenn irgendwas in der Applikation schiefläuft zeigt er das nicht an....

Korrekt. Es haben aber manche User schon eine Verbesserung erziehlt , wenn Sie die Onboard Intel Grafikkarte mal aktiviert haben (!), sofern vorhanden, anstatt einer dediziert eingebauten Grafikkarte.

Es soll bei manchen Usern ja noch Probleme mit dem "Asio-Guard" im Cubase geben. Könnte man auch mal durchprobieren, ob der Ärger macht. Der Asio-Guard hat mir bei hohen Peaks eigentlich ganz gut geholfen, gibt aber User wo der Asio-Guard nicht so prall sich bemerkbar macht und dann schaltet man es doch vielleicht mal aus.
 
also werden CPU Kerne geparkt und das mag so manche DAW und so manches Plugin leider gar nicht
Ja da kann das Plugin/die daw aber scheins relativ wenig machen. Wenn Threads gebildet wurden, dann geschieht das normal zur Leistungssteigerung. Wenn das Betriebssystem den thread dann auf einen kern verschiebt und diesen parkt kann die applikation da erstmal nix machen, dann holpert es halt kurz, bis der kern wieder entparkt ist. Im zweifelsfall könnten sogar kleinere Puffer bei so einem problem das knacksen beseitigen, wenn der core geparkt wird, während ein thread aufgrund vollem audiopuffer nix zu rechnen hat. Wenn der puffer dann leer läuft und der thread wieder anspringen soll, der core aber geparkt ist könnte es knacksen.

Habe auf die schnelle mal rein gar nix zu Multicore Steuerung gefunden, das scheint unter windows ein recht spärlich behandeltes thema zu sein.

Scheint so, dass globales deaktiveren des core parkings über bios oder betriebssystem tools der einzige weg ist....

Die applikation müsste die möglichkeit haben, threads als "dont park" zu kennzeichnen oder sie müsste (workaround) dafür sorgen, dass der thread statisch auf einem kern bleibt und dieser immer was zu rechnen bekommt, um ein parken zu verhindern. Aber wie gesagt, ich habe zu solchen möglichkeiten unter windows nix gefunden und wenn es da nichtes gibt, ist die applikation auf gedeih und verderb dem betriebssystem ausgeliefert.
 
Zuletzt bearbeitet:
also werden CPU Kerne geparkt und das mag so manche DAW und so manches Plugin leider gar nicht
Ja da kann das Plugin/die daw aber scheins relativ wenig machen. Wenn Threads gebildet wurden, dann geschieht das normal zur Leistungssteigerung. Wenn das Betriebssystem den thread dann auf einen kern verschiebt und diesen parkt kann die applikation da erstmal nix machen, dann holpert es halt kurz, bis der kern wieder entparkt ist. Im zweifelsfall könnten sogar kleinere Puffer bei so einem problem das knacksen beseitigen, wenn der core geparkt wird, während ein thread aufgrund vollem audiopuffer nix zu rechnen hat. Wenn der puffer dann leer läuft und der thread wieder anspringen soll, der core aber geparkt ist könnte es knacksen.

Habe auf die schnelle mal rein gar nix zu Multicore Steuerung gefunden, das scheint unter windows ein recht spärlich behandeltes thema zu sein.

Scheint so, dass globales deaktiveren des core parkings über bios oder betriebssystem tools der einzige weg ist....

Da kennt sich einer aber echt gut aus, respekt! Wenn der Kern wieder entparkt wird, kann das betreffende Plugin genau darüber stolpern. Für solche Ungereimtheiten gibt es so Tools wie "Park Control", ist kein Actionthriller , sondern kann man sich installieren und dann entsprechend schauen was da so vor sich geht, wobei natürlich nicht genau in das Plugin selbst rein , ist ja klar denke ich mal.

ParkControl – Tweak CPU Core Parking and More (bitsum.com)
 
also werden CPU Kerne geparkt und das mag so manche DAW und so manches Plugin leider gar nicht
Ja da kann das Plugin/die daw aber scheins relativ wenig machen. Wenn Threads gebildet wurden, dann geschieht das normal zur Leistungssteigerung. Wenn das Betriebssystem den thread dann auf einen kern verschiebt und diesen parkt kann die applikation da erstmal nix machen, dann holpert es halt kurz, bis der kern wieder entparkt ist. Im zweifelsfall könnten sogar kleinere Puffer bei so einem problem das knacksen beseitigen, wenn der core geparkt wird, während ein thread aufgrund vollem audiopuffer nix zu rechnen hat. Wenn der puffer dann leer läuft und der thread wieder anspringen soll, der core aber geparkt ist könnte es knacksen.

Habe auf die schnelle mal rein gar nix zu Multicore Steuerung gefunden, das scheint unter windows ein recht spärlich behandeltes thema zu sein.

Scheint so, dass globales deaktiveren des core parkings über bios oder betriebssystem tools der einzige weg ist....

Da kennt sich einer aber echt gut aus, respekt! Wenn der Kern wieder entparkt wird, kann das betreffende Plugin genau darüber stolpern. Für solche Ungereimtheiten gibt es so Tools wie "Park Control", ist kein Actionthriller , sondern kann man sich installieren und dann entsprechend schauen was da so vor sich geht.

ParkControl – Tweak CPU Core Parking and More (bitsum.com)

Es gibt multicore microcontroller, da sind teils dsp kerne drauf und ein "regulärer" mcu kern, der den dsp über shared memory mit daten versorgt mit sowas werd ichs u.u. demnächst zu tun haben, von daher interessiert mich das thema :)
 

Ähnliche Themen

M
  • Artikel
Antworten
4
Aufrufe
112K
synthpark
synthpark
greenman
  • Artikel
Antworten
4
Aufrufe
50K
sigale
sigale
M
    • Danke
  • Artikel
Testberichte Steinberg Cubase 5
Antworten
1
Aufrufe
76K
Gast62052
G

Neue Antworten


Zurück
Oben