Knacken/Knistern bei kurzer Latenz trotz i6700k

[Shino]

Hallo!

Ich habe ein Problem mit dem Saffire Pro 40 und Sonar Professional.
Das System ist Windows 10 64bit.
Das Projekt läuft in 48kHz.

Wenn ich in "Saffire MixControl" kurze Latenz einstelle, dann knisterts in den Monitoren bei MIDI oder auch bei Mikrofonen.
Wenn ich "medium" einstelle, ist das Problem weg. Allerdings kann es ja irgendwie nicht sein, dass ich mit einem Intel 6700k und 16GB RAM die kurze Latenz nicht nutzen kann. Eigentlich dürfte es kein Problem sein.

Mit dem Buffersize habe ich schon rumexperimetiert, allerdings ohne Erfolg. Es scheint wirklich dann aufzutauchen, wenn ich die Latenz auf short setze.

Gibt es da noch irgendwo irgendwelche Einstellungen, die ich übersehen habe??

\Edit:
ich kann natürlich mit dem Buffersize auf 32 gehen, die CPU dürfte ja dann den Buffer bei größeren Effekten übernehmen, dann habe ich 0,7 Latenz... also sozusagen der Wahnsinn, aber warum geht die "short" Variante nicht?

 

[adrachin]

Was ist denn das für eine Firewire Karte? Und unbedingt im UEFI Virtualisierung ausschalten. Energieprofil Maximale Leistung?

 

[Shino]

Firewire-Karte ist die beste, die es wohl dafür gibt, was die Unterstützung angeht. Musste wegen dem Win10 darauf umsteigen. TI XIO2213B mit einem Kabel 400 auf 800(9pin).

Energieprofil ist auch maximal gestellt, ich habe sogar die Priorität für die Hintergrundprozesse gestellt, obwohl ich mich frage, ob es bei meinem System noch relevant ist.

Die Virtualisierung... hmm... ich such mal danach im UEFI.
--- Beiträge wurden zusammengefasst ---
VT-d (Virtualization Technology for directed I/O) ist aus.

 

[adrachin]

TI-Firewire ist gut. VT-d aus. Hm. Welche Puffergrösse hast Du denn eingestellt und wie testest Du das? Spuren und dann spielen?

Zufällig habe ich ebenfalls einen i7 6700k mit 32 GB. Win 10. Und ein Sonar Test Projekt. Interface Saffire Liquid 56. Das sollte sich nicht all zu sehr von dem Pro 40 Unterscheiden. Das Test Projekt hat 41 Spuren Audio mit Plugins je Kanal MJUC, UBK-1 und Satin. Power Anzeige in Sonar:

also ordentlich Last. Das spielt mit Puffer 32 ohne Dropouts. Firewire Driver Latency in MixControl Medium.

Bringt Dich jetzt zwar nicht unbedingt weiter, ist aber ein Indiz, dass es grundsätzlich möglich sein sollte niedrige Latenz zu erreichen.

Lass doch mal den da laufen:

http://www.resplendence.com/latencymon

vielleicht zeigt der den Übeltäter an........

 

[Shino]

naja... ich hab bei 48000 so ziemlich alles probiert, auch bei 96... bei 96 war das Knacken seltsamerweise bei kleineren Puffergrößen deutlich weniger und bei großen mehr. Bei 48 habe ich den Puffer auf 32 ausprobiert bekam allerdings Knacken, 48 und 64 ging schon besser... vorsichtshalber habe ich jetzt 128 eingestellt.

Den test mache ich ganz einfach mit einem MIDI-Keyboard und einem VST dazu. Habe es vor ein paar Tagen allerdings auch mit Mikro getestet, mit dem gleichen Ergebnis... auch einfach ein wave-File laufen lassen... ebenfalls mit Knacken.

Die Auslastung ist bei mir demnach so ziemlich gleich 0, weil ich ja an sich nur ein paar Spuren hab zum Testen.

Das Latencymon check ich nicht so ganz, aber das sagt:
current measures interrupt to process latency: pendelt zwischen 65 und 165
highest measures interrupt to process latency: 165 (341)
highest reported ISR: 200 (dxgkrnl.sys - DirectX) (216)
highest reported DPC: 226 (nvlddmkm.sys - NVIDIA) (318)
reported total hard pagefault count: 42 (26289)
highest reported hard pagefault resolution time: 717 (2242088)

nach ca. 7 Minuten Laufzeit sprang plötzlich die ganze Sache inh die Luft...
die Werte oben in Klammern.

Das habe ich mit dem eingeschalteten Saffire, aber ohne Sonar ausgeführt.
--- Beiträge wurden zusammengefasst ---
bei hard pagefaults scheint svchost.exe für den Sprung verantwortlich gewesen zu sein.
--- Beiträge wurden zusammengefasst ---
der zeigt mir seltsamerweise 7 CPUs statt 4

 

[adrachin]

Korrektur. Man sollte schon die Augen und Ohren aufmachen, wenn man was testet. Das Ergebnis oben ist ein anderes Interface mit 1024 Puffer. Das Saffire macht abspielen 41 Spuren und Plugins an in 8 Spuren bei Puffer 32. Bei Puffer 64 geht Plugins an in 22 Spuren ohne Dropout. Das ist eher mittelprächtig. Ich habe bessere Ergebnisse gesehen mit anderen DAW. Wobei die DAW jeweils mehr Einfluss hatte auf das Ergebnis als das Interface.

Hier hatte ich mal einige Testergebnisse gepostet:

https://www.musiker-board.de/threads/fehler-in-studio-one-3.639803/page-3#post-7926820

Die Interfaces haben nicht den grossen Unterschied gemacht. Die DAW schon. Wobei ich jetzt kein Spezialist für Sonar bin. Aber da gibt es auch nicht viele Einstellungen im Bereich Audio Engine. Wie auch immer, lass mal hören, was Deine Einstellungen und Testprojekte sind.......

 

[Shino]

hmm.. danke für den Link... der ist zwar informativ... allerdings wird mir mein Problem dadurch nicht klarer.
Warum kann ich nicht in dem Saffire MixControl auf kurze Latenz gehen und DANN den Puffer einstellen UND warum gibt er mir bei 32 Puffer Knackser??

Einstellungen sind ja nicht viele da, oder welche Einstellungen meinst Du?
der Testprojekt ist momentan wirklich nur eine Mikrospur, auf der momentan nichts ist und 5-6 VST.Plugins für MIDI-Keyboard, davon ist nur eine demutet und aufgenommen. Es sind keine zusätzlichen Effekte etc. an. Also ein mehr oder weniger leerer Testprojekt.

 

[adrachin]

bei hard pagefaults scheint svchost.exe für den Sprung verantwortlich gewesen zu sein.

svchost.exe ist ein Host für andere Dienst. Hier muss man rausfinden, was der den gehostet hat und da dann weitersuchen.

der zeigt mir seltsamerweise 7 CPUs statt 4

Wenn schon dann 8. Die zählen ab null.

Den test mache ich ganz einfach mit einem MIDI-Keyboard und einem VST dazu. Habe es vor ein paar Tagen allerdings auch mit Mikro getestet, mit dem gleichen Ergebnis... auch einfach ein wave-File laufen lassen... ebenfalls mit Knacken

Irgendwas spuckt da rein. Du solltest mal in Latency Monitor auf die Reiter Processes und Driver gehen. Da kann man dann sortieren nach Auffälligkeiten. Eventuell hilft das weiter.

Ebenfalls schnell mal gemacht, Device Manager öffnen und alle Geräte, die nicht gebraucht werden deaktivieren. Einschließlich aller Netzwerkgeräte.

Da auch in den USB Root Hubs unter Einstellungen Enegiesparen abstellen.

Was nutzt Du denn für eine Grafik?

Latency Monitor sollte so aussehen:

Klar ist auf jeden Fall, da ist ein generelles Problem irgendwo. Was Du da als Test machst da ist der Rechner ja sozusagen im Leerlauf. Das muss gehen.......

 

[Shino]

jup, so ähnlich sah er bei mir auch aus, bis der komische Sprung nach ca. 7 Minuten kam.
Ich hab in den Reitern geschaut, aber nichts sonderlich Aufschlussreiches gefunden, außer dass die pagefaults ordentlich nach oben schießen... und damit natürlich auch der Rest. Werd mal morgen die ausgelösten pagefaults hier posten... svchost war zwar am höchsten, aber da war auch noch was knapp dran... irgendwas mit ti....exe irgendwas, was mit Windows-Updates wohl zu tun hatte.

Ich versuchs mal morgen mit dem Abschalten unnötiger Hintergrundprogramme etc. und dem Deaktivieren der Geräte.

Nvidia GTX970 nutz ich... also dürfte kein Problem sein.

Danke auf jeden Fall für die Tipps!

 

[adrachin]

Nvidia GTX970 nutz ich... also dürfte kein Problem sein

Sag das nicht. dxgkrnl.sys - DirectX ist Grafik und nvlddmkm.sys - NVIDIA auch. Gegebenenfalls mal die Grafikkarte ausschalten und die interne Grafik des Chipsatzes verwenden. Ich nehme mal an das it z170. Und so lange im Latency monitor immer noch steht

ist das noch im grünen Bereich. Jedenfalls hast Du schon mal ein paar Anhaltspunkte wo Du suchen kannst.

Steckplatz tauschen der Firewire Karte wäre auch noch eine Möglichkeit.

Wird schon.......

 

[Shino]

Aber warum soll die GTX970 ne schlechte Latenz verursachen?
Das müssen ja dann auch irgendwelche Einstellungen sein.

 

[adrachin]

Aber warum soll die GTX970 ne schlechte Latenz verursachen?

Keine Ahnung. Warum sollte ein LAN Adapter dropouts verursachen? An einem meiner Laptops muss ich den deaktivieren. Sonst ist keine Wiedergabe ohne Dropouts möglich......

 

[chaos.klaus]

Die Real-Time-Performance hat nicht so viel mit der Rechenleistung deines PCs zu tun. Es sind eher kleine Störenfriede die Dropouts verursachen. Die zu finden ist leider aufwendig.

 

[Mr. Bongo]

... und auf meinem Laptop musste ich einen vorinstallierten Maustreiber (was zur Hölle sucht der da?) deinstallieren, der selbst einfachste Wiedergabe unmöglich machte. Nicht fragen, warum das so ist, einfach alles durchprobieren und den Störenfried weghauen

 

[SupportFFNov]

Hallo.

Die FireWire-Treiberlatenz beeinflusst die Performance der ASIO-Anwendungen.
Wenn Probleme mit Klick- oder Popp-Geräuschen, bzw. Dropouts auftreten, liegt das möglicherweise daran, dass sich eine Komponente des Computers negativ auf die Leistung der über FireWire angeschlossenen Audiogeräte auswirkt. Anstatt Komponenten (Grafik-oder WLAN-Karte) zu entfernen oder auszutauschen, können solche Probleme möglicherweise durch einen höheren Latenzwert behoben werden.

Gruß, Andreas

 

[Shino]

ok, mal wieder was dazu gelernt
ich schau mal mit den Geräten, die da so rumhängen, was es sein könnte.

@SupportFFNov:
das ist ja klar, dass man die Latenz einfach höher setzen kann. In meinem Fall, habe ich bei der Einstellung "medium Latenz" und Buffersize von ungefähr 96 keine Probleme. Aber das ist ja nicht der Sinn der Sache mit einem intel 6700k. Der müsste eine kurze Latenz und den kleinsten Buffersize gut vertragen können.

 

[Signalschwarz]

Aber das ist ja nicht der Sinn der Sache mit einem intel 6700k. Der müsste eine kurze Latenz und den kleinsten Buffersize gut vertragen können.

Das ist nunmal eine Milchmädchenrechnung.

 

[dabbler]

Das Problem ist normalerweise nicht die Last die die CPU wegschaffen kann, sondern ob irgendwelche Treiber zu lange die CPU zwingend in Beschlag halten bevor sie sich wieder anderen Tätigkeiten (wie z.B. das Verarbeiten von Audiodaten!) kümmern darf. Die CPU-Leistung ist da nur nachrangig das Problem. Blockiert ein Treiber zu lange sog. Context Switches, dann kommen die Audiodaten möglicherweise schneller rein als sie verarbeitet werden können (Buffer läuft über), oder die DAW liefert nicht schnell genug die Audiodaten ans Interface. Dann kommts zu Knacksern etc.

 

[Shino]

Ok, das wird jetzt langsam verständlicher
Kann es dann z.B. sein, dass eine "zu fette" Grafikkarte für ein Recording-System im Audiobereich eher negativ ist? Müsste sie dann minimalistischer sein?

 

[dabbler]

Kann es dann z.B. sein, dass eine "zu fette" Grafikkarte für ein Recording-System im Audiobereich eher negativ ist?

Solange Du nicht nebenbei eine sehr 3D-Grafik-intensive Applikation (sprich: Game ) laufen hast sollte das per se kein Problem sein. Es ist eine Treiberqualitätsfrage. Je schneller die Hardware ist, desto eher kompensiert das jedoch ggfs. vorhandene Treiberprobleme. Insofern: eher nicht - wenn überhaupt dann sogar eher hilfreich, vollständig abhängig vom konkreten Einzelfall (Hardware, Treiberversion etc.)