Noel, this is interesting, because as others have said, some hardware vendors are repeating the same advice. I never could figure out the technical rationale either as I agree with your position here on this. Normally you'd expect Sonar and its in-process DLLs to consist of the primary workload on the machine and therefore everything is happening in a single process context. In that situation, the main unpredictability in scheduling presumably arises from kernel-mode operations performed by device drivers. I suspect that the majority of audio glitch problems stem from issues at the kernel level but unfortunately the DPC latency tool, while useful in potentially highlighting issues, has no means of identifying WHICH drivers might be problematic e.g have unpredictable latency or have serialisation issues (i.e critical sections that tie up resources for lengthy periods of time). As we all know, wifi drivers tend to be particularly appalling in this area but although Microsoft provide some tools to supposedly pinpoint these issues, I've had little luck getting understandable results out of them.

If there's a tool out there that complements the DPC latency checker and allows you to 'profile' driver usage during normal operation, I'd love to know about it, because I suspect it would pinpoint a LOT of these issues in the field. Any suggestions, since you guys must be experts in this area?

The background services tweak is a tweak that is recommended by Steinberg, all other sources essentially take their lead from them. However in this months Sound on Sound and in a bit of a u turn.

I say "can" because although its still recommended by Steinberg (http://knowledgebase.steinberg.net/91_1.html) and has been proven to reduce CPU overheads and cure random audio crackles on many systems over the years, on others it seems to make no difference to performance, and in a few cases it has actually downgraded audio performance.

Not quite the most essential tweak that it is made out to be. Remember this is cross platform and not just for Sonar.

Could be Steinburg runs ASIO as a background/separate service. And we have been told by CW techs that Sonar runs ASIO in process.

Another "tweak"

RME techs, years ago, wrote that they found NO difference in modifying the swap/page file settings. Their recommendation was/is to leave it as system managed.

Yet, it still is on the list of stuff to do. I figger is a program wants to unload from RAM it should have freedom to do so.
I do have the page file on a separate disk, not on the audio disk, nor the OS disk. But it then has free range.

And so on.

J

-------

My equipment:

A small room containing:

chair (semi-confortable)

steel and fiberboard table: generic putty colored keyboard, wheelmouse, analog mixer, control surface, cables (line, clock, midi, and, toslink), grey extension cables

home-made wooden shelving: monitors (audio and video), turntables, tape baker, mics, cassette deck, DVD deck, notes, pencils and pens

Rack: top: 4 track tape deck, patch panels (3x24), computer (8-channel/toslink audio interface), clock, midi interface, noise gate (4 channels), AC power conditioner, enthernet hub,and shelf for notes and stuff

drawers: manuals, disks, adaptors (line, speaker), meters, pedals, effects, mics, headphones, and other stuff

wall shelves (salvaged): tapes (cassette and reel), manuals, parts, boxes, cables

Other: keyboards (about 6), guitars (5), purcussion things (Obtained and found objects}, guitar amps (2), 2-track tape deck, and, other outboard stuff

Stuff that should be OFFFFF::::

ALL scheduled tasks, including AUTO updates, and then the corrosponding services: background intelligent,...

Indexer

UPNP
SSDP

wireless service
windows media sharing

and so on

J

===============================


Remember, when you are working with your music, do not forget to use your index finger on your right hand to click your left button on your mouse to hi-lite your clip in your song on your monitor. And then use your ring finger (or your middle finger) on your right hand to click your right button on your mouse to display your context menu so you can choose from your choices to change your clip in the way you want to,...

And then when you are happy that you did what you wanted to process your clip in your song, click FILE on your menu in your program to save your project to your hard-drive in the folder you want to use to keep all your stuff.

Besides the background services..........

I tweaked my XP installation with nlite. With that you can get rid of a lot of unnecessary XP stuff.
I also disabled a lot of services or set them to manual.

Yesterday I checked the site Oaf_topic posted. Good info there about services.

However when checking I noticed that some services I previously set to manual, were set to automatic again.
Seems that Microsoft decided for me again that I need stuff I don't want.
I guess you'll have to ReTweak your system from time to time.

BTW there are a few exceptions to when BG services might be benefical. An example is Rolands Reac system. The driver for that which Cakewalk developed, is a special ASIO driver that uses a network protocol to communicate with the hardware. This rely's on components/services in Windows to do some of the low level work, and as such benefits from processor scheduling set to BG services. However specialized use cases like this are relatively rare.

Noel Borthwick [Cakewalk
]

I don't recommend this. Setting the sheduling to background for "better performance" with drivers is a myth. At best this is masking a real problem with the driver. All this does is change the quanta for the timeslice assigned by the windows scheduler. By making the time slice longer you are potentially setting up a scenario where the high priority audio threads in the host application might be denied frequent enough servicing by the scheduler! This might actually result in more dropouts or clicks.

Here is a quote from an MSDN article http://support.microsoft.com/kb/308417

• If you click Programs, the foreground program runs more smoothly and responds more quickly. If you want a background task such as a Backup utility to run faster, click Background services.
• The Programs option allocates short, variable time slices (quanta) to running programs, and the Background services option assigns long, fixed quanta.


Contrarary to the SOS article that says "this is the most essential tweak of all, because ASIO drivers run as background services in Windows." An ASIO driver is just another a dll running in the process memory space, its NOT a background service - at least not typically. I've never seen an ASIO driver that installs an actual Windows service (you would see that in the services view otherwise). Its just a DLL running a user mode thread to service the audio device and asio callbacks. The thread is no different from the threads that run in the host application itself. If the driver is coded to have the thread priority set to time critical and its thread is not being blocked by something else there should be no need to change this setting. i.e. for the few people this "helps" its likely that all its doing is masking another more fundamental problem.
Additionally setting the sheduling to background is allowing ALL other background tasks on your computer to get a longer timeslice - i.e some other windows service or background application is now more likely might to start interfering with the host task.

ORIGINAL: epillarbox

Interesting. I also spotted this bit which was news to me:

Change Processor Scheduling to 'Background Services'

Navigate to the Advanced page of the System applet. Click on the Performance Settings button, select its Advanced tab and click on 'Background Services' for Processor Scheduling (see top pair of screens).
pcmusician 2
This is one of the few essential Windows XP tweaks, since it benefits the performance of ASIO drivers, which run as background tasks.

For anyone using ASIO drivers (and nowadays that includes just about every PC musician), this is the most essential tweak of all, because ASIO drivers run as background services in Windows. Music software and hardware developers Steinberg rely on this setting to ensure low latency without dropouts, and you may be able to run your audio interface at a significantly lower latency after this tweak.


So I did this. Result was ghastly on my system (my profile for details if you're interested) so I suppose the moral is to try out tweaks one by one and test their impact one at a time.

Thanks for the link, though.

Laurence


edited for typo

+1 million - Noel is SPOT ON with the above comments.  


Use DPC Latency Checker to see if there are things that are causing latency 'Spikes', and then go through the pain in the bewty part of figuring what those are and then alter/disable/remove them and go back and repeat the cycle of testing and disabling until things are low enough to allow smooth audio streaming.


As an example, I had a (at the the time) pretty powerful laptop running XP Pro, with 4GB and a nice solid-state hard drive in it, and yet I had NASTY latency spikes that made it useless for audio processing.  Through a painful process of trial and error, it turns out that the BATTERY was aging, and THAT was causing the spikes.  As soon as the battery was removed, I had instant perfection on my latency - down to less than 100 us.


This is one of the most frustrating parts of getting things up and running for audio processing, you just sort of have to march your way through methodically until you get it figured out.  For some, it is things like the battry, for others, perhaps the wireless radio needs to be turned off, yet others maybe some parallel port needs disabling.  


I think I can safely say that most, if not all, of us feel the pain of what you are going through.  I will try to monitor this thread and chime in on anything I see go by where I might have some helpful comment.


Good luck, 


Bob Bone

Bob, this post is four years old - a lot of this stuff just isn't relevant any more.