Jump to content

Severe dropout and static during playback and recording.


Heb Gnawd

Recommended Posts

Apologies for the length of this post, Its a complex knot and I've been at it a long time. The problem is sporadic and doesn't seem to follow any consistent logic.

I'm writing here after several weeks of running the well-beaten trail of this problem with the usual suspects, (sound card and Microsoft support). I have not changed anything significant in the last year but suddenly encountered severe dropout and static about 3 months ago. The static is sometimes only heard and not recorded, the dropout sometimes so severe I get the blue screen ( blue screen report only says Windows stopped unexpectedly). The dropout records as an electric buzz.

Here is a short synopsis of questions, a longer description follows:

-Could 2 video cards ( both NVIDEA) using the same driver cause this

-Could 4 monitors cause this, ( sometimes disconnecting a monitor or disabling one of the cards ( 2 monitors) seems to reduce the chance of dropout ( or red ink in latency monitor)

-Could there be a physical electrical problem , (short circuits, overloaded power demands)

-Is there an inherent Windows 10 problem with sound recording revolving around the ACPI Driver for NT routine?

I am running windows 10 Pro up to date ( latest build) on a SSD drive, projects and VST banks on a separate SSD drive. Board is MSI Z390-A Pro with i7 3.6Ghz and 64 G of RAM. I have a Native instrument controller (USB powered) and a digital piano connected via separate midi cables to a Powered USB bar that is plugged to a USB 3.1 Gen 2 port. I have 2 sound cards ( not using simultaneous, just to say I've swapped them out and the problem persists) Focusrite scarlet 2i2 and EVO 8. I believe I have swapped out every component listed above including the computer. I do not experience this problem with the same sound card connected to my laptop running Windows 10 Home.

Windows, sound card drivers, video card drivers and chipset drivers are up to date, ( and throttling is disabled). Power settings are specifically set for sound recording (including disabling USB suspected suspend). This problem persists after deactivating all other unrelated devices, (network card, Realtek onboard sound, wacom tablet, NVIDIA high definition audio)

I am turning in circles because behavior is not repeatable. Running a test several times produces a consistent result one day and not another. At times I thought the problem could be electrical, because I often get shocks ( little sparks) in my headphones that cause the mic light to flash which means they are being recorded. But they don't correspond to moments of static while recording and the shocks aren't new. For a short period it seemed as I was getting a correlation between dropout and touching the keyboard or pedal of the piano, but that too was not consistent. Computer and 3 monitors are connected to one bar, midi controller, USB bar, piano and a fourth monitor are connected to a second bar, each bar to separate 3 prong outlets. USB bar has both MIDI USB cables and the NI controller power.

Steps taken

Starting with the sound card I explored the full range of buffer settings, and then ( with tech support) installed and ran latency monitor several times while recording. I ran the utility many times while experiencing dropout and static, Latency Monitor blames a large spectrum of services and devices on my computer rarely the same. ( dxgkrnl.sys direct X, nvlddmkm.sys - NVIDIA Window, ACPI.sys - ACPI Driver for NT. The ACPI driver is the current darling culprit for this problem on the Microsoft forum, because latency monitor frequently records that it is the highest DPC routine execution time. I am starting to ask the question what is causing the ACPI Driver for NT routine to overrun?

On one occasion I tried swapping out Cakewalk ( I have the latest update but the problem has survived at least 2 updates) I ran latency monitor while recording a single audio track in Cakewalk and then in Audacity. Latency Monitor turned red within seconds during the Cakewalk recording which produced static all the way along and dropout that recorded as an electric buzz yet it remained green during the Audacity recording which produced no static or dropout. The latency monitor reports are very similar (expect one is red and one is green) both showing Direct X as the highest ISR Routine execution time and NVIDEA as the most DCP routine execution time with roughly the same numbers. However, these results, just like every other test I run are not consistent, immediately afterwards the cakewalk recording produced a green “suitable for audio” conclusion???

On another occasion it seemed to be the weight of playing back multiple VST banks. I open a new project file and record midi with no problem then add an audio track that produces static while recording but which is not recorded, then I open a full project with multiple tracks and I experience dropout and latency monitor flashes red.

Any help with this problem would be greatly appreciated.

Thanks

Edited by Heb Gnawd
error
Link to comment
Share on other sites

Hi Tecknot, thanks for your response.  

Sound card sample rate is  set to 4800 Mhz, buffer size is 256,  Cakewalk is set the to the same sample rate, using ASIO Mode my understanding is that the bit rate is fixed at 24.  Usually when there is a conflict I hear a tick as the project opens and realize that Cakewalk has reset my sound card to  match the project configuration. I'm not sure how to set sample rate in Windows, my Windows sound settings defer to the device selected. 

Drop out and static occurs also with brand new project files with nothing more than a single audio track, but the more severe blue screen drop outs are from heavily packed  projects with many virtual instruments.  In such cases I have gone through the project deleting track by track to observe changes, for a while I was thinking there was a problem with one of the libraries. There could very well be more than one thing going on here. But I've never found a clear identifiable culprit.

Regards

Heb

Edited by Heb Gnawd
Link to comment
Share on other sites

Pull the GPU cards and test with Intel graphics only. Post your LatencyMon reports.

If that doesn't help, then your best bet would be to temporarily disconnect everything that you don't absolutely need to boot the computer and test, for example bare bones with just a monitor, PC keyboard, mouse, and audio interface.

If good, then start adding one thing back at a time, testing each time, until the problem returns. If it does, there's your culprit.

 

Edited by abacab
Link to comment
Share on other sites

OK , Thanks for the suggestion, I,ll pull out the video cards and test, I'd have to pull the cards to activate the on-board video, I haven't done that yet. I have disabled all nonessential devices to no avail. So am I understanding that as far as you know this has to be a device /software problem? Sparks in my headphones is a red herring?

Link to comment
Share on other sites

13 minutes ago, Heb Gnawd said:

So am I understanding that as far as you know this has to be a device /software problem? Sparks in my headphones is a red herring?

Probably a device problem for the dropouts, as they are often driver related, but you won't be sure until you rule everything out. That headphone thing sure is weird, but if you eliminate everything you may figure that one out as well. It almost sounds like a faulty electrical ground somewhere.

I run a Z-390 board myself, and it is rock solid on Windows 10 2004. It also ran well with just the Intel graphics before I added an NVIDIA GPU. I get very low numbers on LatencyMon, and never any dropouts or static, assuming I am running with a reasonable ASIO buffer size. I also use a Focusrite Scarlett 2i2.

But if you have been at it for weeks, it's time to start breaking it down. Process of elimination and good old troubleshooting 101. :)

Edited by abacab
Link to comment
Share on other sites

  • 1 month later...

SOLVED!

Ok  I'm back after more than a month of  trial and error.  I wanted to update this post in case anyone in the future finds themselves where I was. Imagine my surprise when the dropout problem survived , stripping the system of video cards and all non relevant drives , then a clean re-install of Windows followed by days of re-installation of ILOK, and other security software as well as 650 GB of virtual instruments.  The culprit was, what I thought were SSD drives ( Seagate Firecuda 2TB SSHD). I have since learned the difference between SSHD and SSD, even though both are billed as "Solid state" drives  and ( in the case of the Firecuda) pretend speeds of 5 times that of traditional drives. These drives may start out at 125 mbs ( which is actually lower than my traditional HDD ) but they degenerate over time, such that 6 months after formatting they were read / writing at 70 mbs, ( which despite Seagate's claim is actually less than half the speed of traditional drives). As soon as I replaced these "hybrid" drives with real SSD drives the problem disappeared.  This was probably a mistake not many of you would have made which is why it wasn't considered. 

Thanks for all your help , very happy to get out of computer tech and back to music after many months.

 

Edited by Heb Gnawd
error
  • Thanks 2
Link to comment
Share on other sites

I'm not an expert but I dont think SSHD is tech terminology. I think its a marketing term ( scam) which appears to be exclusive to Seagate.  In my view its tarnishing Seagates reputation more than any money it might be making them. Truth is if I had never upgraded to these "Solid State "drives and kept my original HD drives I would never have had this problem. My HD drives in the SATA III ports of the z390A are reading at 170mbs. 

SO,  yes the Z390A remains "rock solid" if you avoid weak link components. ( My wife always tells me  " respect yourself and your tools, don't buy the cheapest!)

Best Regards and thanks for your help

 

Link to comment
Share on other sites

On 3/18/2021 at 4:44 PM, Heb Gnawd said:

SOLVED! ... I wanted to update this post in case anyone in the future finds themselves where I was. ...  As soon as I replaced these "hybrid" drives with real SSD drives the problem disappeared.  This was probably a mistake not many of you would have made ....

Truly, it's wonderful that you got to the bottom of this issue.  I wish I had seen this thread earlier, as I could have saved you some heartache. 

Back in 2015, I had a plan to add two more SSHD's (a reasonable term for a hybrid HDD) to the two that I already had in order to build a very interesting RAID array.  Things went badly *very* quickly, and that flavor of the project was abandoned.  It's documented in the 2nd article of a 5-article series on my website.   [ https://www.tedlandstudio.com/torpedo-at-the-dock ]

The additional SSD cache in the HDD of a hybrid drive isn't especially effective because its small size makes it inherently slow, and it's not especially well-matched to media-based workloads that audio and video creates.  Since then, I've made quite a few combinations of hybrid hard drives, and finally, at this time, I use a limited-horizon approach to this by using PrimoCache.

You can read my summary description of PrimoCache, and the way that I use it in two posts that I did on another forum: [ https://www.gearslutz.com/board/showpost.php?p=15353007&postcount=13648 ] 

https://www.gearslutz.com/board/showpost.php?p=15354350&postcount=13655 ]

Thanks OP for closing the loop and updating us with the solution!

Edited by MediaGary
typo
Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...