Får dropouts i Cubase trots helt nyinstallerat kraftigt system

suprapappa · 14 augusti 2018

Hallå!

Jag har precis gjort en nyinstallation av Windows 10 och har en skapligt kraftig dator:

CPU: Intel i7 76000 4ghz

Minne: 16gb

Moderkort: MSI PcMate 170z

Ljudkort: RME Fireface UC

Jag kör Cubase 8.5 och 9.5 och alla drivrutiner till ljudkort, grafik, chipset är uppdaterade.

Innan jag installerade om (drabbades av en krasch av systemdisken) fick jag också dropouts i Cubase och dom kvarstår till min förvåning nu när systemet är helt fräscht. Jag har laddat upp en låt där "Audio Performance" som man får upp med F12 ligger och myser på c:a 45% på "average load" , "real time peak på c.a 10% och "disk" ger inte utslag överhuvudtaget. "Average Load"-stapeln slår dock i taket med hyfsat jämna mellanrum. När låten inte spelas upp slår den i taket med bara några sekunders mellanrum.

Jag vet att jag såg någonstans i någon tråd om något program som kunde logga datorns processer. Jag minns dock inte vad det heter och än mindre kan jag tolka resultaten. Jag vill minnas att jag testade det för något halvår sedan men minns som sagt inte namnet.

Är det någon som har koll på ett sådant program och som skulle kunna hjälpa till att tolka datat?

Tack!

KillwithSkill · 14 augusti 2018

Finns mkt skit i windows...
https://pcforalla.idg.se/2.1054/1.634644/windows-10-spionera-installningar

https://support.focusrite.com/hc/en-gb/articles/207355205-Optimising-your-PC-for-Audio-on-Windows-10

Redigerat 14 augusti 2018 av KillwithSkill

14 augusti 2018

Har du provat att byta usb kontakt på moderkortet?

peterT · 14 augusti 2018

Prova

https://www.thesycon.de/eng/latency_check.shtml

Har du trådlöst nätverk på datorn, prova stäng av det.

van Caine · 14 augusti 2018

Den här listan har jag följt slavist, och har inte haft tillstymmelse till dropout på studiodatorn på över ett år, och då har jag ändå inbyggda mätare i ljudkortet som kollar bittransparensen på varenda liten sample hela vägen från inspelningen till utspelningen ?
Datorer är egentligen helt värdelösa på audio, men det finns hopp.

http://www.prismsound.com/music_recording/support_subs/support_tech.php?tt=0023

Redigerat 14 augusti 2018 av van Caine

van Caine · 14 augusti 2018

Längst ner på sidan finns en massa trevliga länkar som kan ge dig djupare inblick i vad som kan tänkas jävlas.

15 augusti 2018

7 timmar sedan, van Caine säger:

Den här listan har jag följt slavist, och har inte haft tillstymmelse till dropout på studiodatorn på över ett år, och då har jag ändå inbyggda mätare i ljudkortet som kollar bittransparensen på varenda liten sample hela vägen från inspelningen till utspelningen ?
Datorer är egentligen helt värdelösa på audio, men det finns hopp.

http://www.prismsound.com/music_recording/support_subs/support_tech.php?tt=0023

Nej. datorer är inte helt värdelösa på audio. Men de datorer vi använder för audio är byggda för något annat som tex ordbehandling och databaser.

van Caine · 15 augusti 2018

Datorer är inte gjorda för realtidsbehandling på bittransparent nivå, det gör dem helt värdelösa "out of the box". Dock kan de ofta ställas in för att funka, eller i vart fall ha så lite hörbara glitchar som möjligt.
Dock inte alltid. Gick igenom tre moderkort till AMD under nån gång under mitten av 2K-talet innan jag gav upp och köpte Intel med ett erkänt arbets-chipset istället. Det är lätt att tänka att mycket har hänt sen dess, och det har det, men när jag förra månaden försökte få en AMD-laptop att spela in ljudeffekter, och den ilskna röda "dropout-lampan" i VeriFile lös som ett stroboskop, insåg jag även att mycket är sig likt. Verifile är Prism Sounds eget system för att kolla dropouts. Varje enskild sample får en inkodad checksum vid inspelning direkt från ljudkortet, innan datorn ens vet att det finns ett ljud, inkodad i ljudets absolut lägsta bitnivå. Om den inte stämmer när det sen spelas upp och filen inte är processad på nåt sätt så har nåt gått fel. Den XEON jag köpte förra året funkar dock fint, har inte haft en enda sample dropout sen förra våren, då jag först började peta i listan jag delade här ovan. Den Core2Duo-processor jag jobbade med under 10 år innan dess funkade efter att jag köpte ett moderkort med rätt chipset.
Chipset om något verkar vara en enorm nyckel till att få det att funka transparent efter processorn själv.

suprapappa · 15 augusti 2018

16 timmar sedan, KillwithSkill säger:

Finns mkt skit i windows...
https://pcforalla.idg.se/2.1054/1.634644/windows-10-spionera-installningar

https://support.focusrite.com/hc/en-gb/articles/207355205-Optimising-your-PC-for-Audio-on-Windows-10

Har testat det mesta där men det hjälper inte. Många av tipsen från Focusrite kändes som sånt man ställde in redan på Win XP.

15 timmar sedan, pme säger:

Har du provat att byta usb kontakt på moderkortet?

Japp men icke.

suprapappa · 15 augusti 2018

Tack så mycket alla för era svar! Jag har en diger lista att beta av.....kanske ska börja med att uppdatera BIOS?

Jag TROR att programmet jag sökte var Process Monitor https://docs.microsoft.com/en-us/sysinternals/downloads/procmon

Råkar det vara ngn som förstår datat som kommer ut i loggfilen?

Detta fel känns väldigt mycket som en konflikt från någon annan process. Det är inte samma typ av knäpp och dropouts som när ett projekt är väldigt ansträngt och man kör med för låg latency, fast om jag har ett i stort sett tomt projekt utan pluggar så uppstår det inte. Testade att bypassa alla pluggar på någon låt men det hjälpte inte heller.

Problemet uppstår inte på samma sätt under inspelning utan endast (?) under uppspelning och "spikarna" i Audio Performance-monitorn syns visuellt även när en låt är pausad och alltså tyst.

van Caine · 15 augusti 2018

Jag rekommenderar verkligen att gå igenom hela listan jag skickade här uppe. Prism är inte bara ett av de absolut högsta inom vad de gör, och denna enkla lista är verkligen en väldigt snabb väg att få saker bättre. Jag hade massvis av dropouts innan jag optimerade med den som fullständig checklista.
Dock, det som gjorde den absolut största skillnaden, var att stänga av en jobbig funktion i både Win8 och Win10 , under strömsparsinställningarna, där man kan välja om USB får stänga av sig godtyckligt eller inte! Med den bort så blev det wroom wroom för mig. Alla problem lösta.
Här är en schysst beskrivning direkt på lösningen:

https://www.windowscentral.com/how-prevent-windows-10-turning-usb-devices

MX3 · 15 augusti 2018

Programmet du letar efter bör vara Latency Monitor som du gratis kan ladda ner via:

http://www.resplendence.com/latencymon

Här är bra en guide för audio-optimering. Kapitel 3.2 beskriver hur du använder Latency Monitor för att identifiera problemen.

https://support.native-instruments.com/hc/en-us/articles/209571729-Windows-Tuning-Tips-for-Audio-Processing

Video-versionen

Redigerat 15 augusti 2018 av MX3

Neosus · 15 augusti 2018

Allt förnyas och tekniken blir allt bättre (eller?). Vilket chipset är det som gäller idag?

Kanske ska starta en egen tråd förresten? 😳 😱

suprapappa · 15 augusti 2018

Högst märkligt!!!

Jag uppdaterade mitt BIOS och det var ganska många versioners skillnad. Det förra var från 2016 och den nya från i år.

Efter det när jag körde MSI Live Update hittade den Intel ME Drivers som jag också uppdaterade.

När jag startade det "mellanlastade" projektet som tidigare låg på c:a 45% på "average load" hade denna mätare ökat till c:a 70% medan realtime peak-mätaren slog i taket stup i kvareten. Dock utan några dropouts!! När dropparna har kommit förut är det average load-mätaren som har slagit i taket. Detta var i Cubase 8.5

Laddade ett projekt i 9.5 som är väldigt tyngt av pluggar. Med låg latency låg båda mätarna i taket och det gick inte att spela upp. Efter att ha ändrat bufferstorlek från 96 till 1024 samples går det fint att spela upp och hittills har jag inte hört några dropouts men averagemätaren ligger mellan 90-99% medan realtime peak knappt ger synligt utslag.

Ska testa latency monitor när jag hinner. Tack @MX3

2 timmar sedan, Neosus säger:

Allt förnyas och tekniken blir allt bättre (eller?). Vilket chipset är det som gäller idag?

Kanske ska starta en egen tråd förresten? 😳 😱

Diskussion om vilket chipset kanske passar bättre i en separat tråd men frågan är högst relevant. Mitt förra system som jag tror hade en Pentium 4 som CPU ....edit: jag ser i min profil att det var en Core 2 Quad 6600 och inget annat 🙂 och på vilket jag mixade vår förra platta hade inte detta problem med dropouts. Detta var nog 8-10 år sedan. Däremot klarade det inte samma mängd pluggar och dyl.

Vet inte om jag ska göra en BIOS downgrade.......känns lite konstigt med mätarna även om vad som låter naturligtvis är viktigast.

Redigerat 15 augusti 2018 av suprapappa

15 augusti 2018

3 timmar sedan, Neosus säger:

Allt förnyas och tekniken blir allt bättre (eller?). Vilket chipset är det som gäller idag?

Kanske ska starta en egen tråd förresten? 😳 😱

X599

remote · 18 augusti 2018

På 2018-08-15 på 15:29, suprapappa säger:

Högst märkligt!!!

Jag uppdaterade mitt BIOS och det var ganska många versioners skillnad. Det förra var från 2016 och den nya från i år.

Efter det när jag körde MSI Live Update hittade den Intel ME Drivers som jag också uppdaterade.

När jag startade det "mellanlastade" projektet som tidigare låg på c:a 45% på "average load" hade denna mätare ökat till c:a 70% medan realtime peak-mätaren slog i taket stup i kvareten. Dock utan några dropouts!! När dropparna har kommit förut är det average load-mätaren som har slagit i taket. Detta var i Cubase 8.5

Laddade ett projekt i 9.5 som är väldigt tyngt av pluggar. Med låg latency låg båda mätarna i taket och det gick inte att spela upp. Efter att ha ändrat bufferstorlek från 96 till 1024 samples går det fint att spela upp och hittills har jag inte hört några dropouts men averagemätaren ligger mellan 90-99% medan realtime peak knappt ger synligt utslag.

Ska testa latency monitor när jag hinner. Tack @MX3

Diskussion om vilket chipset kanske passar bättre i en separat tråd men frågan är högst relevant. Mitt förra system som jag tror hade en Pentium 4 som CPU ....edit: jag ser i min profil att det var en Core 2 Quad 6600 och inget annat 🙂 och på vilket jag mixade vår förra platta hade inte detta problem med dropouts. Detta var nog 8-10 år sedan. Däremot klarade det inte samma mängd pluggar och dyl.

Vet inte om jag ska göra en BIOS downgrade.......känns lite konstigt med mätarna även om vad som låter naturligtvis är viktigast.

På 2018-08-15 på 15:29, suprapappa säger:

Du löser all med MX3 förslag, enket att köra och ger svar på alla dina problem!

Enklast att se videon. Du kan hoppa in i mitten när de visar Latency Monitorn

MX3 skrev:
Programmet du letar efter bör vara Latency Monitor som du gratis kan ladda ner via:http://www.resplendence.com/latencymon

Här är bra en guide för audio-optimering. Kapitel 3.2 beskriver hur du använder Latency Monitor för att identifiera problemen.

https://support.native-instruments.com/hc/en-us/articles/209571729-Windows-Tuning-Tips-for-Audio-Processing

Neosus · 18 augusti 2018

På 2018-08-15 på 17:26, pme säger:

X599

Okay! ☺️

suprapappa · 20 augusti 2018

Tack igen för svar! Har inte hållit på med det på några dagar då jag inte varit hemma.

Detta blir märkligare och märkligare. Efter att ha uppdaterat till senaste BIOS-versionen som tycktes göra att mina performancemätare sköt i höjden fick jag en blåskärm när jag skulle starta datorn. Det stod ngt i stil med att Windows behöver samla information om felet och startar därefter om. Jag har fått detta tidigare någon gång och det har inte varit något problem men nu blev det samma sak två gånger i rad varpå det stod att jag behöver göra en systemåterställning.

Mkt frustrerard stängde jag av datorn och gick iväg för att äta lunch. När jag kom tillbaka bootade den helt normalt. Installerade nu Latency Monitor och när jag nu laddar Cubase så ser performancemätarna ut som före BIOS-uppdatering och dropoutsen VERKAR vara borta. Även resultaten i Latency Mon ser bra ut.

Ghost in the machine!!! Håll tummarna för att det håller i sig!

Itzhak · 30 januari 2019

jajaja... sent svar men det kanske hjälper någon annan.

kolla så att du Inte har hyper-threading aktiverat i ditt bios; när jag bytte dator så var det en av de första sakerna jag fick ändra för att få bort cpu-peakarna.

van Caine · 30 januari 2019

16 minuter sedan, Itzhak säger:

jajaja... sent svar men det kanske hjälper någon annan.

kolla så att du Inte har hyper-threading aktiverat i ditt bios; när jag bytte dator så var det en av de första sakerna jag fick ändra för att få bort cpu-peakarna.

Steinberg verkar må bäst med hyperthread aktiverat, själv blev mitt Nuendo märkbart slöare med det avstängt. Väldigt delade åsikter om vad som är bäst där, enligt Pro Tools-användare jag snackat med så verkar det vara att föredra där, men i många andra fall inte.

suprapappa · 23 november 2019

Hallå!

Bumpar min gamla tråd. Uppdaterade nyligen till Cubase 10.5 och har fortfarande helv*tiska problem med dropouts vilket tar knäcken på mig. Jag har testat några att sakerna som nämns ovan men långt ifrån alla. Mycket av det känns som ett sätt att "kräma ur" all kraft ur sin dator och problemet här tycks inte alls relaterat till belastning. Om jag t.ex. sitter och spelar gitarr i Cubase med endast en gitarrplugin samt Addictve Drums igång så slår min audioperformance-mätare ändå i botten med c.a 20 sekunder mellanrum och jag får dropouts.

Naturligtvis har jag uppdaterat drivrutiner för ljudkort, grafikkort mm.

Jag har åter testat att köra Latency Mon men problemet är att jag inte förstår resultaten...Det finns något som heter " REPORTED HARD PAGEFAULTS" som tycks hänga ihop med mina dropouts. Den visar: Process with highest pagefault count: och nyss när jag körde den rapporterade jag mitt antivirusprogram (Norton) och jag trodde att jag hade hittat problemet. Testade att stänga av Norton men det hjälpte inte och istället stod någon annan process i listan. Nu senaste hette den "svchost.exe".

Har även testat att aktivera nätverkskortet men inte heller det hjälper.

Undrar om det finns någon ytterst vänlig och kunnig själ som kan kika på min loggfil från Latency Mon och se om den pekar på något? Klistrar även in två skärmdumpar på flikarna "processes" och "drivers" från samma program.

Tusen tack!

_________________________________________________________________________________________________________
CONCLUSION
_________________________________________________________________________________________________________
Your system appears to be suitable for handling real-time audio and other tasks without dropouts.
LatencyMon has been analyzing your system for 0:02:19 (h:mm:ss) on all processors.

_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name: DESKTOP-7H26C4P
OS version: Windows 10 , 10.0, build: 18362 (x64)
Hardware: MS-7971, MSI, Z170A PC MATE (MS-7971)
CPU: GenuineIntel Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
Logical processors: 8
Processor groups: 1
RAM: 16273 MB total

_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed: 4008 MHz

Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.

WARNING: the CPU speed that was measured is only a fraction of the CPU speed reported. Your CPUs may be throttled back due to variable speed settings and thermal issues. It is suggested that you run a utility which reports your actual CPU frequency and temperature.

_________________________________________________________________________________________________________
MEASURED INTERRUPT TO USER PROCESS LATENCIES
_________________________________________________________________________________________________________
The interrupt to process latency reflects the measured interval that a usermode process needed to respond to a hardware request from the moment the interrupt service routine started execution. This includes the scheduling and execution of a DPC routine, the signaling of an event and the waking up of a usermode thread from an idle wait state in response to that event.

Highest measured interrupt to process latency (µs): 329,20
Average measured interrupt to process latency (µs): 3,825003

Highest measured interrupt to DPC latency (µs): 311,70
Average measured interrupt to DPC latency (µs): 1,218195

_________________________________________________________________________________________________________
REPORTED ISRs
_________________________________________________________________________________________________________
Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal.

Highest ISR routine execution time (µs): 100,888473
Driver with highest ISR routine execution time: Wdf01000.sys - Kernellägesdrivrutin för Framework Runtime, Microsoft Corporation

Highest reported total ISR routine time (%): 0,012496
Driver with highest ISR total time: Wdf01000.sys - Kernellägesdrivrutin för Framework Runtime, Microsoft Corporation

Total time spent in ISRs (%) 0,013155

ISR count (execution time <250 µs): 168139
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-999 µs): 0
ISR count (execution time 1000-1999 µs): 0
ISR count (execution time 2000-3999 µs): 0
ISR count (execution time >=4000 µs): 0

_________________________________________________________________________________________________________
REPORTED DPCs
_________________________________________________________________________________________________________
DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.

Highest DPC routine execution time (µs): 389,056886
Driver with highest DPC routine execution time: ntoskrnl.exe - NT Kernel & System, Microsoft Corporation

Highest reported total DPC routine time (%): 0,330718
Driver with highest DPC total execution time: Wdf01000.sys - Kernellägesdrivrutin för Framework Runtime, Microsoft Corporation

Total time spent in DPCs (%) 0,414965

DPC count (execution time <250 µs): 685925
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-999 µs): 5
DPC count (execution time 1000-1999 µs): 0
DPC count (execution time 2000-3999 µs): 0
DPC count (execution time >=4000 µs): 0

_________________________________________________________________________________________________________
REPORTED HARD PAGEFAULTS
_________________________________________________________________________________________________________
Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution.

NOTE: some processes were hit by hard pagefaults. If these were programs producing audio, they are likely to interrupt the audio stream resulting in dropouts, clicks and pops. Check the Processes tab to see which programs were hit.

Process with highest pagefault count: svchost.exe

Total number of hard pagefaults 27
Hard pagefault count of hardest hit process: 6
Number of processes hit: 12

_________________________________________________________________________________________________________
PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s): 10,621986
CPU 0 ISR highest execution time (µs): 100,888473
CPU 0 ISR total execution time (s): 0,145646
CPU 0 ISR count: 168069
CPU 0 DPC highest execution time (µs): 311,629990
CPU 0 DPC total execution time (s): 4,476695
CPU 0 DPC count: 651425
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s): 6,004867
CPU 1 ISR highest execution time (µs): 48,461826
CPU 1 ISR total execution time (s): 0,000638
CPU 1 ISR count: 70
CPU 1 DPC highest execution time (µs): 224,494012
CPU 1 DPC total execution time (s): 0,097980
CPU 1 DPC count: 10812
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s): 3,328980
CPU 2 ISR highest execution time (µs): 0,0
CPU 2 ISR total execution time (s): 0,0
CPU 2 ISR count: 0
CPU 2 DPC highest execution time (µs): 157,290669
CPU 2 DPC total execution time (s): 0,011764
CPU 2 DPC count: 6004
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s): 3,941094
CPU 3 ISR highest execution time (µs): 0,0
CPU 3 ISR total execution time (s): 0,0
CPU 3 ISR count: 0
CPU 3 DPC highest execution time (µs): 25,837575
CPU 3 DPC total execution time (s): 0,002998
CPU 3 DPC count: 2261
_________________________________________________________________________________________________________
CPU 4 Interrupt cycle time (s): 2,902629
CPU 4 ISR highest execution time (µs): 0,0
CPU 4 ISR total execution time (s): 0,0
CPU 4 ISR count: 0
CPU 4 DPC highest execution time (µs): 389,056886
CPU 4 DPC total execution time (s): 0,007383
CPU 4 DPC count: 4615
_________________________________________________________________________________________________________
CPU 5 Interrupt cycle time (s): 3,500837
CPU 5 ISR highest execution time (µs): 0,0
CPU 5 ISR total execution time (s): 0,0
CPU 5 ISR count: 0
CPU 5 DPC highest execution time (µs): 222,842565
CPU 5 DPC total execution time (s): 0,001112
CPU 5 DPC count: 648
_________________________________________________________________________________________________________
CPU 6 Interrupt cycle time (s): 3,067792
CPU 6 ISR highest execution time (µs): 0,0
CPU 6 ISR total execution time (s): 0,0
CPU 6 ISR count: 0
CPU 6 DPC highest execution time (µs): 54,095808
CPU 6 DPC total execution time (s): 0,013399
CPU 6 DPC count: 8031
_________________________________________________________________________________________________________
CPU 7 Interrupt cycle time (s): 3,401613
CPU 7 ISR highest execution time (µs): 0,0
CPU 7 ISR total execution time (s): 0,0
CPU 7 ISR count: 0
CPU 7 DPC highest execution time (µs): 39,410928
CPU 7 DPC total execution time (s): 0,003084
CPU 7 DPC count: 2134
_________________________________________________________________________________________________________

YellowStudio · 24 november 2019

Kan inte dom där data grejorna men vad har du för buffer size?

Har du aktiverat cubase audio power scheme?

aktiverat multi processing?

24 november 2019

Hur ser det ut med dina hårdvaru interrupts? Det brukar inte vara några problem på moderna maskiner men det kanske kan vara värt att kolla i alla fall. Jag skulle även prova att koppla in ett externt pcie usb kort.

24 november 2019

När man googlar på moderkortet så framgår det att nån gång i början när det lanserades så hade det tydligen problem med Kingston minnen. Kanske hårdvaru fel eller problem med konflikter beroende på interna kort som sitter i olycklig kombination och skapar flaskhalsar. Testa att byta plats på tex ditt grafikkort och se vad som händer.

24 november 2019

Page faults får man försöker läsa en sida i minnet som inte lägre finns kvar. Datorn får då hämta in den från disken. Vad har du för diskar i datorn? Typiskt så är antivirus bra på att se till att sidor tas bort från ramminnet. Dvs datorn tycker att det är bättre att använda ramet till antivirus. När du provade att stänga av antivirus, startade du om datorn?

peterT · 24 november 2019

Har inte läst hela tråden, så har du redan gjort detta så strunta i mitt meddelande.

https://helpcenter.steinberg.de/hc/en-us/articles/360008589880-Windows-10-How-to-set-up-and-optimize-a-Digital-Audio-Workstation-DAW-

En sak jag skulle göra något åt är alla chrome.exe du har i processes.

Och kör en memtest för att kolla ramminnet.

suprapappa · 24 november 2019

10 timmar sedan, YellowStudio said:

Kan inte dom där data grejorna men vad har du för buffer size?

Har du aktiverat cubase audio power scheme?

aktiverat multi processing?

Min buffer är 96 samples, vilket förstås är hyfsat lågt och har jag ett högt belastat projekt får jag ibland höja lite i mix. Detta är dock en annan typ av dropouts som uppstår även vid nästan noll belastning.

Multi processing var aktiverat.

Heureka!!! Efter att jag nyss klickade i "Cubase audio power scheme" så har inte dropoutsen uppstått sedan dess....har dock bara hunnit testa några minuter. MEN det känns som att problemet kvarstår fast Cubase fick mer kraft att hantera problemet. Bockar jag ur det så slår mätarna i taket igen och dropoutsen är tillbaka. Jag vill gärna felsöka detta vidare då jag tänker att det bör funka "out of the box" utan en massa tweakande.

10 timmar sedan, pme said:

Hur ser det ut med dina hårdvaru interrupts? Det brukar inte vara några problem på moderna maskiner men det kanske kan vara värt att kolla i alla fall. Jag skulle även prova att koppla in ett externt pcie usb kort.

Hoppas jag förstår det rätt....har kollat i enhetshanteraren efter IRQ-konflikter och hittar inga.

Finns det fördelar med ett externt USB-kort? Hanterar det USB-portar bättre än de som sitter på moderkortet?

10 timmar sedan, pop53 said:

När man googlar på moderkortet så framgår det att nån gång i början när det lanserades så hade det tydligen problem med Kingston minnen. Kanske hårdvaru fel eller problem med konflikter beroende på interna kort som sitter i olycklig kombination och skapar flaskhalsar. Testa att byta plats på tex ditt grafikkort och se vad som händer.

Minnena är av märket HyperX Fury. Grafikkortet är integrerat på moderkortet och är av typen Intel HD Graphics 530. Moderkortet heter MSI PcMate 170z (det står något annat i beskrivningen i min profil men jag hittar inte hur jag ändrar det.)

Just grafikkortet är väl det jag mest har misstänkt men har inga belägg för det.

10 timmar sedan, pme said:

Page faults får man försöker läsa en sida i minnet som inte lägre finns kvar. Datorn får då hämta in den från disken. Vad har du för diskar i datorn? Typiskt så är antivirus bra på att se till att sidor tas bort från ramminnet. Dvs datorn tycker att det är bättre att använda ramet till antivirus. När du provade att stänga av antivirus, startade du om datorn?

Nej, jag startade inte om men gjorde om det nu och startade om. Det hjälpte dessvärre inte.

6 timmar sedan, peterT said:

Har inte läst hela tråden, så har du redan gjort detta så strunta i mitt meddelande.

https://helpcenter.steinberg.de/hc/en-us/articles/360008589880-Windows-10-How-to-set-up-and-optimize-a-Digital-Audio-Workstation-DAW-

En sak jag skulle göra något åt är alla chrome.exe du har i processes.

Och kör en memtest för att kolla ramminnet.

Har ofta väldigt många flikar öppna i Chrome men att stänga ner dom hjälpte inte heller. Inte heller att koppla bort nätverk. Ska köra memtest.

Tusen tack för allas input!!!

24 november 2019

Poängen med ett externt usb kort att man kommer bort från eventuella konstigheter i bios. USB är ganska besvärligt när man ska kunna göra saker som att att väcka sovande dator, konstiga emuleringar av tangentbord så att A20 prylar fungerar osv. Ser man till vad peterT länk säger så bör du prova ett USB2.0 eftersom du har ett USB2.0 ljudkort och det finns lite problem med att mixa med USB3. Har du några usb kontakter som inte är blå (usb3) så prova att använd dessa för dit ljudkort.

24 november 2019

Jag skulle nog testa med att låna ett pcie ljudkort och ett riktigt grafikkort och stänga av onboard grafiken och inte köra nåt annat program än din DAW.

Usb kan vara lite fippligt som PME säger så dubbelkolla att det sitter i rätt port först.

På min gamla gigabyte hackmac som har den första usb3 standarden måste jag tex göra en omstart för att slippa störningar i bilden från mina Camlink usb3 capturekort varje gång jag startar upp datorn. Utöver det så måste jag också dra ur och sätta i dom igen efter omstarten innan mina program ser dom men sen funkar det bra.

Min har ju några år på nacken så din ska ju vara rena kanokulan jämfört med min.

Som en jämförelse så kör jag två tunga program för ljud och video med tre capturekort, ett pcie och som sagt två usb3 för livestreaming, Chrome, Logic och sen kanske jag screencappar nåt med Quicktime simultant.

Håller jag mig till 720p så rullar datorn på ganska bra. Har i och för sig inte kört nåt saftigare arr i Logic med en massa plugins på den ännu då den är mera till Live köret.

Logic har ett M-Audio Delta 1010 Pci ljudkort som också systemet har tillgång till. Livestreamens ljud matas från Delta kortet till capturekortets analoga ingångar (stereo) så den kör med två ljudkort igång samtidigt.

Jag har min gamla kvar som kör med samma processor som din gamla hade och den fixade nästan samma belastning allaredan för 9 år sedan men har dock inte usb3.

Ett jäkla skumt fel du har åkt på för som sagt den ska kicka skiten ur dom här två av mina datorer i alla fall.

Redigerat 24 november 2019 av Gäst

YellowStudio · 25 november 2019

96 samples låter väldigt lågt. Jag kör 256, iofs på en äldre maskin men jag hör ingen latency eller annat som stör.

Vad kör du för projekt upplösning?

Sånt påverkar också. Det är sällan man behöver gå över 48/24. Det är om man jobbar mycket med stems som det kan vara idè att gå högre har jag läst.

Redigerat 25 november 2019 av Lindpop

Logga in

Får dropouts i Cubase trots helt nyinstallerat kraftigt system

Recommended Posts

pme (oregistrerad)

pme (oregistrerad)

pme (oregistrerad)

pme (oregistrerad)

Gäst

pme (oregistrerad)

pme (oregistrerad)

Gäst

Bli medlem (kostnadsfritt) eller logga in för att kommentera

Bli medlem (kostnadsfritt)

Logga in

Senaste foruminläggen

Liknande innehåll

Utvalda pressmeddelanden

Just nu inloggade (Visa hela listan)

Viktig information om kakor (cookies)