[wnmnkh]

[size=medium]1. Introduction. [/size]



The aim of this thread is to provide information, solution and discussion about sound cracking (or popping, skipping, etc), a.k.a dropout. This thread will be updated if there are other members' input via replay posts on this thread. I made this thread because there are TONs of same question over and over again throughout interweb.

Make no mistake; when working well, computers are ultimate source for today's audiophiles with much improved sound card's performance (even on-board cards are better than some of past's old hi-fi sources) and scalability with various sources (files, CD, DVD-A, streaming, able to receive inputs from various devices) It is bad idea to just give up like "my computer is lemon, and computers suck for listening anyway" if you think about what you can done with your computer.

[size=medium]

2. Why is sound from my computer so dirty?[/size]



From Thesycon - USB and IEEE 1394 Software Development, USB and Firewire Device Drivers development

Quote:

Processing of streaming data in real-time is a very challenging task for Windows based applications and device drivers. This is because by design Windows is not a real-time operating system. There is no guarantee that certain (periodic) actions can be executed in a timely manner. Audio or video data streams transferred from or to an external device are typically handled by a kernel-mode device driver. Data processing in such device drivers is interrupt-driven. Typically, the external hardware periodically issues interrupts to request the driver to transfer the next block of data. In Windows NT based systems (Windows 2000 and better) there is a specific interrupt handling mechanism. A device driver cannot process data immediately in its interrupt routine. It has to schedule a Deferred Procedure Call (DPC) which basically is a callback routine that will be called by the operating system as soon as possible. Any data transfer performed by the device driver takes place in the context of this callback routine, named DPC for short. The operating system maintains DPCs scheduled by device drivers in a queue. There is one DPC queue per CPU available in the system. At certain points the kernel checks the DPC queue and if no interrupt is to be processed and no DPC is currently running the first DPC will be un-queued and executed. DPC queue processing happens before the dispatcher selects a thread and assigns the CPU to it. So, a Deferred Procedure Call has a higher priority than any thread in the system. Note that the Deferred Procedure Call concept exists in kernel mode only. Any user-mode code (Windows applications) runs in the context of a thread. Threads are managed and scheduled for execution by the dispatcher. While there is a pre-emptive multitasking for threads, DPCs are executed sequentially according to the first in, first out nature of a DPC queue. Thus, a sort of cooperative multitasking scheme exists for Deferred Procedure Calls. If any DPC runs for an excessive amount of time then other DPCs will be delayed by that amount of time. Consequently, the latency of a particular DPC is defined as the sum of the execution time of all DPCs queued in front of that DPC. In order to achieve reasonable DPC latencies, in the Windows Device Driver Kit (DDK) documentation Microsoft recommends to return from a DPC routine as quick as possible. Any lengthy operation and specifically loops that wait for a hardware state change (polling) are strongly discouraged. Unfortunately, many existing device drivers do not conform to this advice. Such drivers spend an excessive amount of time in their DPC routines, causing an exceptional large latency for any other driver's DPCs. For a device driver that handles data streams in real-time it is crucial that a DPC scheduled from its interrupt routine is executed before the hardware issues the next interrupt. If the DPC is delayed and runs after the next interrupt occurred, typically a hardware buffer overrun occurs and the flow of data is interrupted. A drop-out occurs.

Faulty drivers/hardware, mismatch between external sound interface and computer, and/or even just outdated driver/software can cause sound degradation. Simple issues like power plan on notebook computers also contribute sound cracking.

Same site is giving away a nice latency checker to diagnosis the problem, in which you can also find quoted paragraph as well.


DPC Latency Checker


With some research, I came to a conclusion that most of cases, which are not solvable via quick tweaks such as changing power plan, are caused by...


1.) Graphic Card.

2.) Wireless Card.

3.) Sound Card Driver.


But for third case, it is often related to first case, graphic card, which seems to be the source of the problem most of the time. This info would save you a lot of time trying to find out which device making trouble by shutting down devices one by one.


[size=medium]
3. Solutions.[/size]



By no means the fixes present here are complete.

First, change your Graphic card driver. You may want to check if this would work by simply uninstall the driver first, then play sound while no graphic card driver installed (only basic windows driver activated). Either upgrade OR downgrade the driver may solve the problem.

For Nvidia users you may want to visit NVIDIA & Laptop News | Latest NVIDIA drivers and related news | laptopvideo2go.com which is de facto driver download site for both desktop and notebook users. You will find newest and old versions of drivers.

For ATI/AMD users also can find old version of drivers on various sites such as Old Version Downloads - OldApps.com

Same goes for wireless card and sound card, but you may want to just turn off wireless if you can use Ethernet connection. Even if it is solved wireless cards are also main factor of conflicts and high latency.

There are other solutions besides changing drivers.

1.) Use alternative protocol such as ASIO or Kennel streaming. But, it is rather incomplete solution since programs do not use these will still suffer.

2.) Turn off certain effects on graphic card, and/or downclock core may solve the issue.

3.) Kill/delete processes going on the machine. If resource is low, many playback applications will run out of memory very quick.

4.) For USB external sound interface, simply changing the port it's using may solve the problem because it also changes the device's IRQ allocation.

5.) Force graphic card to work on 100% regardless of the load. Only notebook case applied. Will drain battery like mad, and potentially shorten the lifespan of the machine.

6.) If all else fails, you may want to consider change the computer's OS. Windows in general, especially newer windows 7 are infamous for sound quality problems in general. Try better OS such as linux would not hurt you.

Any inputs and discussion are welcomed.

 

[athenaesword]

hmm appreciate the effort, but the reasons given seem pretty few and don't suggest anything to do with power supplies of components, where in many cases i've read that ppl have solved their issues with additions of power conditioners or made an effort to clean up their power supplies.

 

[Hybrys]

Yeah... I've almost always seen it related to Wireless cards. As for your solutions:

2) Makes no sense. Turning certain things off on the graphics card doesn't do a damn thing. And all lowering the clock will do is... Lower the clock. If you want to play with power, you have to lower the VCORE.

3) Not specific enough. I can just see people 'killing' SVCHOST over and over, and restarting over and over, and etc. Better advice: During dedicated listening sessions, you can turn off security things like your Anti-Virus or Firewall to save resources, aswell as closing background applications such as Limewire, Torrent applications, Steam, browsers, and etc.

4) Too vague. USB buses are usually coupled or quadrupled. Try moving it as many slots away as possible. If you currently have it plugged in the front, try the back, or the other way 'round. Try to thing of things in twos. If there are two horizontally aligned, they're probably on the same bus.

5) Again, playing with power to a notebook's graphics card seems... vague and unwarranted. Nevermind just ASKING for overheating issues. Intelligent stepping is, UH, intelligent. If something else fixes the problem, use that instead. IE: My laptop's power supply is really susceptible to dirty power. Thus, when I'm at work, I plug it into the same power as our amps. Or when I'm at home, I just temporarily unplug my computer, and let it run on batteries.

6) Switching OSes doesn't change much. XP-based to Vista-based systems is a bit of a change, but, Mac/Linux OSes don't offer much of a change in quality. A properly setup system, no matter the OS, works perfectly. And where is this hearsay from about Win7 being BAD for audio? Linux elitist bull.

 

[athenaesword]

lol since we're into it, i honestly doubt modern day computers will introduce artifacts into audio from too many processes. most, if not nobody, will be listening to audio critically while running card or cpu on 100% anyway.

most new cards switch between loads when you run 3D apps that require more graphic power. I'm not sure it's even possible to run cards at 100%, not to mention it's a surefire way to kill your card wayy earlier than it would normally die.

OSes is a fairly crappy point as well, since there's not real indication that sound quality differs between OSes, considering XP and above.