Automatically setting cpu affinity for SAC

[Angie]

This is a new thread based on a discussion here http://www.sawstudiouser.com/forums/showpost.php?p=193443&postcount=11

As mentioned in the above thread, changing the affinity for SAC to run on only one CPU can help with performance on some systems. In my case, it eliminated dropped buffers when using a remote. Yes, you can use the /onecpu switch at boot. But some times you don't want to eliminate both CPUs. Or you can use the single cpu menu setting in SAC itself, but that didn't work for me. I needed to set to a specific CPU. Setting affinity manually to the second CPU was the answer. But in a volunteer situation, having it done automatically is best.

Enter a utility program called Imagecfg. This is a microsoft utility that was available in the 2000 server toolkit and may already be in the windows directory for Vista and up, but is not in XP. You can download it here. http://www2.robpol86.com/guides/ImageCFG/
This page gives instructions on it's use. The only thing you really need to know is the command line switch for setting the process affinity (-a) and the CPU value.

The information on the web on Imagecfg.exe is slightly confusing. There are discussions on using batch files for the program you want to change, etc. But none of that is necessary. Run once, Imagecfg PERMANENTLY changes the hex image of the effected program itself. Because of the nature of SAC, you can run the program once on any computer and simply copy the effected SAC.exe to any machine that needs to run SAC on a single, specific CPU.

So, here's what you do. Put imagecfg.exe in the SAC directory. (You can actually run it from anywhere, even a flashdrive.) From a command prompt, use this string.
C:\SAC\imagecfg -a 0X02 "C:\SAC\SAC.exe"
SAC will now run on the second CPU EVERY TIME it loads. (Change the "2" for other CPUs)

You know it worked if the date on SAC.exe has changed to that days date. Test further by looking at the affinity for SAC in the task manager.

Hope this is helpful.

[Trackzilla]

Very nice info Angie

[RBIngraham]

+1, thank you for posting this info

[Bruce Callaway]

FWIW, I use this for setting affinity for SAC & SAW on startup and as Angie says, it works very well.

[Paul Henry]

I've used Imagecfg in the past for older programs that didn't speak multiprocessor. It always did the job well.

[Donnie Frank]

Thanx, Angie. Because my present system is so solid, I have been leery of upgrading my older socket LGA-775 for this very reason. Thanx for this information!

[Carey Langille]

OK, so, this sounds very cool, But im not sure i completely understand.. SAW/SAC will run now on your second CPU, will then other things run on CPU one? How about VST's do they stay on CPU 2 with SAW or do they use 2 or 1 or whatever? How do they Interact with each other? Inquiring Minds WANT TO KNOW! :D Has Bob explored this in the past?

[RobertV]

OK, so, this sounds very cool, But im not sure i completely understand.. SAW/SAC will run now on your second CPU, will then other things run on CPU one? How about VST's do they stay on CPU 2 with SAW or do they use 2 or 1 or whatever? How do they Interact with each other? Inquiring Minds WANT TO KNOW! :D Has Bob explored this in the past?

Carey;
Please have a read through this,
http://www.sawstudiouser.com/forums/showthread.php?t=7032&highlight=affinity

Re; VSTs and Affinity etc..

Cheers...Robert V

[tomasino]

Dittos.. Thanks Angie!

In the past, toyed with the /ONECPU and internal app. settings, but never noticed any diff.. n' don't know where I left it.

Gonna implement this on the studio rig just to set and forget it.

[tomasino]

Dittos.. Thanks Angie!

In the past, toyed with the /ONECPU and internal app. settings, but never noticed any diff.. n' don't know where I left it.

Gonna implement this on the studio rig just to set and forget it.

Implemented this last weekend.
Started on the ground floor by disabling hyperthreading in the BIOS. (was still enabled.. who knew! :eek: )
Ran imagecfg on SAC.exe n' set its' affinity to the 2nd core (i3 2 core 3.4 Gigawatts )
In Sawstudio set "Force Single CPU".

So, should have:


Sawstudio on core Zero
SAC on core One

Then, experienced a little weirdness in Sawstudio on BuildMix.. but nothing a reboot didn't clear up.
Have had some stuttered start boot ups.


There should be no problem for the Win7 OS with disabling hyperthreading in the BIOS right?
Pretty sure it was ON when the OS was installed.
OS is installed on an SSD drive.

Otherwise seems to be OK.
Not noticing any diff in the MultiTrack/SAC load.

[Angie]

Not noticing any diff in the MultiTrack/SAC load.

I didn't see a difference on my studio machine either.
I don't think it will make a difference in most systems.

My studio machine is an ASUS/Intel.
The church system I needed the fix on is a Gigabyte/AMD that I did not have a hand in building.

Either way, it is easy enough to give it a try. One never knows if it might help.

[nHaskin]

Angie,
I read a post a few years ago when I was working on building a sac host. That stated that SAC worked better on the 2nd core of amd64 machines. I tried it and all my issues went away. I was able to run 1x64 buffers with 2 remotes running. I can't find the original post now, but it mentioned using car.exe Core Affinity Resident. Which loads with every boot. Your method circumvents the resident program, saving memory and cpu cycles. Thanks.

BTW: I wouldn't recommend running Saw on the 1st core at the same time though, tomasino. They will be fighting for memory access. Run them both on the same core & turn the buffers up on Saw. It doesn't need to run in real time.

Ned

[RBIngraham]

I didn't see a difference on my studio machine either.
I don't think it will make a difference in most systems.

My studio machine is an ASUS/Intel.
The church system I needed the fix on is a Gigabyte/AMD that I did not have a hand in building.

Either way, it is easy enough to give it a try. One never knows if it might help.

The point here might be .... if it ain't broke, don't fix it. :)

If you system is running fine, just leave it alone, but this is something to try if you're having a problem. Maybe I'm a fool, but I basically trust the OS, hardware and such to perform best all by itself and I only bother to intervene when something isn't working. Call me nuts.

[RBIngraham]

Angie,
I read a post a few years ago when I was working on building a sac host. That stated that SAC worked better on the 2nd core of amd64 machines. I tried it and all my issues went away. I was able to run 1x64 buffers with 2 remotes running. I can't find the original post now, but it mentioned using car.exe Core Affinity Resident. Which loads with every boot. Your method circumvents the resident program, saving memory and cpu cycles. Thanks.

BTW: I wouldn't recommend running Saw on the 1st core at the same time though, tomasino. They will be fighting for memory access. Run them both on the same core & turn the buffers up on Saw. It doesn't need to run in real time.

Ned

If you're running SAW and SAC at the same time, the buffer settings in SAW mean nothing, only the buffer setting in SAC matters. At least if you're using the SAC-SAW link anyway.

[tomasino]

I didn't see a difference on my studio machine either.
I don't think it will make a difference in most systems.

My studio machine is an ASUS/Intel.
The church system I needed the fix on is a Gigabyte/AMD that I did not have a hand in building.

Either way, it is easy enough to give it a try. One never knows if it might help.
Thanks again Angie.
My mobo is a Gigabyte Z68 with the integrated video etc...

Good to know.

The video production system is an AMD 6core.. might apply this there too n' see how it goes. (i.e. apply it to SoundForge, MovieStudio etc...)

[tomasino]

If you're running SAW and SAC at the same time, the buffer settings in SAW mean nothing, only the buffer setting in SAC matters. At least if you're using the SAC-SAW link anyway.
That's exactly my work/data flow.
SAC is doing the monitoring (almost always) driving the phones and the monitors.

Thanks.

[tomasino]

The point here might be .... if it ain't broke, don't fix it. :)

If you system is running fine, just leave it alone, but this is something to try if you're having a problem. Maybe I'm a fool, but I basically trust the OS, hardware and such to perform best all by itself and I only bother to intervene when something isn't working. Call me nuts.
If it ain't broke... you're absolutely right.
But it was an unknown "ain't broke".

I have a bit more confidence now that I know it's configured to a more optimal set up.
Maybe this'll help avoid some pain later on when recording the next live band scenario.

Thanks again.

[RBIngraham]

. (i.e. apply it to SoundForge, MovieStudio etc...)

Just my guess, since I'm not a code writer, but I would expect Sound Forge is based on much more modern code and therefore likely handles dual or more core situations better than SAC or SAW. I would just leave well enough alone, but that is just me.

[Bob L]

Your guess is ridiculous... and you should just leave things you don't understand alone. :)

Bob L

[RBIngraham]

Well I guess it's just dumb luck then that I never have to mess with this kind of thing in other audio software. :rolleyes:

[Carl G.]

Well I guess it's just dumb luck then that I never have to mess with this kind of thing in other audio software. :rolleyes:

You might look up 'Assembly Language Programming' to understand one of the reasons why Bob made that statement. Your guess did make me chuckle.

[RBIngraham]

You might look up 'Assembly Language Programming' to understand one of the reasons why Bob made that statement. Your guess did make me chuckle.


Not sure why my premise was off the wall (as you must have initially typed in and then changed your mind, because that is what was sent to me via email). Basically my point was.... for the most part you don't need to bother with this stuff with other software. Why? I don't know.

But the truth is SAC and SAW are the only software I've worked with that has to turn off hyperthreading and sometimes tinker with which core of the CPU the software is running on. Other software just does the work for you. If you're so damn smart, explain that please? :)

What language software is written in shouldn't have anything to do with it. And if it does, then perhaps it's time to ditch it and work with some more modern development tools?

You can chuckle all you like, but I would wager you know I'm right, you just prefer not to poke the bear. As usual the minute you point out any short comings in SAC or SAW around here all the knickers get in a twist.