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

Noel, thanks for your detailed contribution here. It's reassuring to have my empirical view endorsed by solid technical expertise.

Laurence

Wow, and all this time I thought this was a major tweak. Thanks so much for clearing that one up Noel!

Take care!


EDIT: This merits a run through the Sonar Benchmark test. Hopefully I'll see some improvements.

Recently I changed motherboards and had lots of trouble getting the audio interface on its own IRQ. I was getting an occasional drop-out. So I went hunting.

So, after doing all the winodws things (set restore points often) do the IRQ thing.

BIOS setup: disable all devices not used: on-board audio, serial ports, parallel port, USB, non-used drive channels: SATA, IDE,..... Some BIOS have a setting to disable polling of unused RAMM slots. And so on.

I only one USB device: A USB 1.0 midi interface, and do not use a usb mouse/keyboard, so I disabled usb legacy and usb 2.0.
Then in windows I disabled all USB ports that were not in use.

I was then, finally, able to get the sound card on its own IRQ.

J


----------------------------
Generic putty color keyboard, wheelmouse, 2 monitors,
grey extension cables for mouse, keyboard, and monitors,
AC extensions, steel and fiberboard 60" table, home-made wooden shelving,....

ORIGINAL: Jose7822

Wow, and all this time I thought this was a major tweak. Thanks so much for clearing that one up Noel!

Take care!


EDIT: This merits a run through the Sonar Benchmark test. Hopefully I'll see some improvements.

Jose,

Done any benchmarks with and without this tweak?

ORIGINAL: Houndawg

ORIGINAL: Jose7822

Wow, and all this time I thought this was a major tweak. Thanks so much for clearing that one up Noel!

Take care!


EDIT: This merits a run through the Sonar Benchmark test. Hopefully I'll see some improvements.

Jose,

Done any benchmarks with and without this tweak?

Hey Houndawg!

First of all, Happy New Year! I hope you had a great time on New Year's Eve.

Now, to answer your question, I did try Noel's suggestion and noticed a slight improvement setting Processor Scheduling to Programs. I was only able to squeeze out two extra Multiband Compressors before any glitches or droputs against having the Scheduling set to Background Services. It's small but an improvement nontheless, so I'll take it . Unfortunately, I also noticed that my dual monitor setup came at a higher price since, with the higher monitor resolution, the number of MC plugs I was able to get before dropped a bit. I like the new resolution though so I'll just live with it. Give it a try and tell us how it went for you.

Take care!

ORIGINAL: 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.

I just had to bump this, since EQ mag just repeated the background services myth that Noel busted here.

You do not say what type of material is having dropouts. But your sig seems to indicate you are running an AMD 1.5 ghz processor, 1 GB of ram and a single hard drive. If you are running a demanding project on that hardware, you may not have to look very far for the source of clicks and pops. Freezing tracks might be more useful than operating system tweaks.

Original: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.

quote:

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



< Message edited by Noel Borthwick [Cakewalk] -- 12/13/2007 8:38:44 AM >

_____________________________

Noel Borthwick
CTO, Cakewalk
CD - A New Leaf

OK, here's where things gets confusing. The following text in bold italics was copied directly from the instructions for setting up the Edirol FA-66 provided by Edirol included in the download file for the drivers from Edirol website ( http://www.rolandus.com/products/productdetails.aspx?dsection=d_downloads&ObjectId=731 ). I'm using the FA-66 Driver Version 1.0.2 for Windows XP 32-Bit Edition. Extract all and click the Readme_E.htm.


Before you begin
"Performance Options" settings of System Properties
Our tests show that occasional disruptions in the sound may occur if the following setting is not made. By making this setting, you may be able to alleviate the problem. Please be sure to make the setting before using the unit.

Open the "Control Panel," and double-click "System." * If the above icon cannot be found, click the "Performance and Maintenance," and click the "System."

Click the "Advanced" tab, and then click [Settings] in "Performance."
Click the "Advanced" tab.
Select "Background services," and click [OK].

Click [OK] to close "System Properties."

I believe this is exactly the same unit as Cakewalks SPS-66 sold with SONAR POWER STUDIO 660. Also note that Edirol is part of Roland just as Cakewalk is now a part of Roland. I'm not trying to dismiss what Noel is saying. In fact I never set my processor scheduling for background services. However, it can be really confusing seeing two sources saying completely different things.

Perhaps I'm not understanding the issue? Or perhaps it's interface dependent?

And this leads me to another point. If cakewalk would just come out with specifications for a couple systems known to work (motherboard and all the other hardware including the audio interface) including how to set up the operating system for optimal performance Cakewalk might see many of the negative posts on this forum go away. Personally, I'm lucky as my current system runs very stable. However, my previous system I could not get to work for the life of me (and I was working in IT setting up computer systems at the time).

However, no one wants to take responsibility for doing this I guess. I mean, you could just add some kind of disclaimer that you would not be held responsible for any problems.