Education Wanted: Windows 10 64 now Stable, Why?

[Nathan P]

I was trying to get SAC 4.2 to function and be stable but kept getting slipped buffers. That was until I went into the BIOS and set it to run on only one of the 2 CPU's - as I've read Bob L & others recommend at times. I was surprised it seemed to work and SAC was stable.

When I tried to reverse the bios settings to determine if that was a consistent possible solution in the future, the system was now also running SAC on one or both cores and was stable no matter whether the state of the following SAC options were checked ON or not: Force Single CPU, Force CPU Blocking, Force HighPriority Class or Force RealTime Priority Class. The BIOS setting to the other single CPU then back to the previous setting was the only thing I changed from the unstable operation of SAC to the now stable operation of SAC.

This is a computer that formerly ran SAC successfully on XP Pro 32 bit OS and was now being tested using 10 Pro 64 bit. The Motherboard was DQ35JO, e6850 Core 2 Duo, 4GB Ram, etc.

In the past I never could get any SAC to be as stable in either 7 64 bit or 10 64 bit OS on my other systems as when they were using 32 bit XP. (In those tests I primarily used the FoxConn G41MX 2.0 motherboard instead.) In the future I want to be able to install newer 64bit OS's on my systems rather than my older XP 32bit OS's. This is the reason I decided to reach out to folks here on this forum - to help me (or others) prevent any similar hard to explain, yet avoidable SAC install failures in the future.

Any thoughts out there regarding what might explain this stabilization of this system?

[Bob L]

My guess is that more than one thing was changed between the two conditions. Don't forget... when you rebooted, SAC reloaded its prefs and possibly reset certain options that you think you had turned off... just a thought.

In general... you can use the 64 bit Win 7, 8 or 10... in most cases you should be able to achieve stability by just setting the realtime priority in SAC and also trying the single cpu setting in SAC... those two things should work.

You can do a little better by using the single cpu setting in the bios... but tthat affects your whole machine for other programs as well.

If you want to keep 2, 4 or 8 cores active for use with other programs... try using the CPU blocking option... that will only affect SAC and should tame the slipped buffers.

Of course... as I have always said... XP still gives the best performance and stability because of the thread scheduling engine... this has been drastically changed in the newer Windows versions and no longer handles priorities the same way as XP did... this can drastically affect the slipped buffer issue.

Bob L

[Nathan P]

If it is true that multiple variables were changed all at once, I have no idea at the moment how to identify them. In multiple earlier failed attempts to adjust, alter, stabilize, etc. the system. It was rebooted, SAC was opened, closed, altered, started, stopped etc. multiple times with no improvements prior to the BIOS settings.

Maybe I will have to wait until I run into trouble on my next system to finish learning how to troubleshoot further SAC system setups.

[virtualmixingconsole]

I use win10 64 bit os with 32 buffer settings, 32 channel, Raydat card, 12 stereo iem, Superior drummer, 2 Acer touchscreen...no slipped buffer...enough stable

Balint

[mr_es335]

Hello,

I have used the DQ35JO board for many years - great board.

My suggestions:

1. Leave the cores as they are - all on.
2. Enable: Force Single CPU.
Note: I have not upgraded, so I am still using v3.1 - no real need for me to upgrade at this point.
3. Enable: Force RealTime Priority Class
4. I prefer to stop and disable the SSD Service.
5. Disable the pagefile.
Note: I find this one pretty interesting when it comes to system performance.

What I/O are you using. I only use RME.

I think that it is very important that "we compare oranges with oranges". What I mean is, is just because someone is getting good results, does not necessarily mean that you will. In my present scenario, I tested six different motherboards and found many problematic. Same processor, ram I/O card - it was just the board that was different. As I am very familiar with your existing board, you can obtain good/excellent results with that board. I would suggest getting an e8400 processor however - they work better with this board and can be obtained quite inexpensively.

Hope this helps?

[Nathan P]

On this board I have primarily used Presonus gear - StudioLive 1642 or FireStudio 2626 though I also have a PCI controlled Motu 24I/O. In this most recent and suddenly successful test I was using the StudioLive 1642. (Between these Motu vs. Presonus units, I found that if one was stable under SAC the other audio device was also stable even though one was FireWire & the other PCI audio.)

(I have owned (3) DQ35JO units all purchased second hand. All but one have started to fail when being used for SAC. I chose that model because of the built in FireWire chip. The first DQ35JO came with an e8400 processor, when that board started failing I tried and failed in reaching acceptable performance using an brand new AMD A8 5600k processor with a MSI A85XA-G65 setup 3 years ago. That gave me horrible results until 512 buffers - the only thing I know I failed to try with that setup was try using the BIOS to restrict the use of extra cores. When all the other attempts on the AMD/MSI combo failed, I bought my other (2) DQ35JO computers, but with the (2) e6850 processors instead - since I knew all my previous e8400 & e6600 processors worked even though their capabilities were different. After the second DQ35JO started failing in relatively short order running SAC in a similar manner to the first, I decided to abandon the DQ35JO motherboards as a purchase option - in spite of the fact it had a Presonus approved Firewire chip. I feared Intel had a bad run of that model. I bought (2) FoxConn G41MX2.0 motherboards to test and have an identical backup. They worked as good as the DQ35JO for me but did not have built in Firewire. In July this summer my primary FoxConn motherboard locked up 4 times then failed to boot into bios after my last event. (Moving the hard drive into my backup Motherboard case resulted in a completely operational system immediately - it also was a confirmation why I like to have (2) almost identical machines, the second ready for a same day backup scenario.)

My SAC work this week was an attempt to setup the one remaining DQ35JO that has not failed me during SAC testing or event use to have one last SAC capable computer I could fall back to even though I'd have to update drivers if I wanted to swap my FoxConn hard drive into the DQ35JO backup machine to salvage information.

mr_es335,
What OS have you had success with using this board?
Would you mind sharing, if easy enough, what other motherboards you've used and their results?

[mr_es335]

Nathan,

Regarding your questions:

Q1: What OS have you had success with using this board?
R1: WINXP Pro and WIN7 Pro.

Q2:Would you mind sharing, if easy enough, what other motherboards you've used and their results?
R2: Of the seven that I have recently tested, the ASUS Z170-P was the best overall.
Note: This unit is in my current build, which I will let everyone see when it is all completed.

Regarding FireWire, under WIN7, that you have the drivers set to "Legacy". See here (http://www.motu.com/techsupport/technotes/using-the-legacy-firewire-driver-in-windows-7)

Interestingly, I tried the FireStudio 2626 and did NOT have great success with it. The Mackie Onyx Blackbird is very good - with the Focusrite Pro 40 being OK, but really not the best either.

[Nathan P]

In general... you can use the 64 bit Win 7, 8 or 10... in most cases you should be able to achieve stability by just setting the realtime priority in SAC and also trying the single cpu setting in SAC... those two things should work.Bob L

I just installed Cubase 4 to allow me to see its estimated Latency (even if I know the values it gives add up to approx. 2ms less than the real world total In+Out latency). When I started up Cubase for the first time while SAC was running, it locked up the audio driver and I could no longer get SAC to process the Presonus driver audio even after multiple reboots. That was until I did a complete uninstall, restart, install, restart, etc. of the Presonus driver to get the Presonus to be recognized again in the Device Manager.

What I noticed was that during this round of SAC tests is that the audio was not stable unless the "Force RealTime Priority Class" was checked. Before it was stable for a couple days without needing that checked. I guess the positive thing is that it appears stability is still possible even if the settings to achieve it have not been consistent. (This a bit mentally demanding considering all three of these states have been on this one system.)

Any additional thoughts on this Bob, or others?
Does it seem likely at all that my first install was not a very good one, allowing both success and failure in SAC and ultimate install failure? (Possibly meaning that this last one is a normal & consistent install - keeping my fingers crossed hoping for this for this to be true in this setup.)

[mr_es335]

Nathan,

Jus curious, how many processes do you have running?

Are you using a antivirus?

[Nathan P]

I have not found a way to stop the Windows Defender from running in Windows 10. I never install Anti-Virus.

It appears at the moment that there are 60 processes running at the moment visible in Task Manager.

[mr_es335]

Hello,

Yes, you have to disable Defender.

Also, that is large number of processes...it would be interesting to discover just what these are.

[Bob L]

60 processes is pretty normal for Win 10... and pretty hard to reduce in practice... another issue which is part of the interference of realtime audio processing in today's Windows versions.

Many audio drivers are not capable of running ASIO modules on multiple programs at the same time, which may explain the Cubase crash and lockup when trying to run SAC at the same time.

Bob L

[Nathan P]

I was able to drop about 10 Processes by uninstalling or disabling some background apps, default apps or those that wanted to run at startup. (Movie & TV, XBox, Splashtop, Realtek Manager, Adobe Acrobat Update Service, etc.)

Referenced:

http://www.cnet.com/how-to/how-to-uninstall-default-apps-in-windows-10/ and
http://www.ghacks.net/2015/10/25/how-to-disable-windows-defender-in-windows-10-permanently/

Also:

Run: services.msc - (which appears to be useful as well.)

[TomyN]

You can control a lot of processes in the task - sheduler. There are some processes that will start when special conditions are meet (idle state, certain time .... ) so there's a lot of possiblities that the current state of your system is not exactly the same as it has been the last time you've tested it.

I discover that in win8 / 10 starting SAC during system start gives me a lot of slipped buffers, but starting it delayed makes the system 'rock - solid' (over 40 Inputs and 8 outputs 64/1 for five hours without any lost buffer).

Tomy

[Nathan P]

This morning I rebooted the system after making all my changes: uninstalls, disabling, etc. listed in an above post with referenced info sources. The system now boots and settles down to 43 process (44 with task manager). SAC says it is running with only the Force RealTime Priority Class checked at 34-36% Load, Task Manager says 22% CPU, 33% Memory

I left the system on all night and it did not slip any buffers. That is good, but I noticed as soon as I tried to resize the main SAC window to view the Task manager beside it, the buffers slipped and were audible the entire time I was adjusting the size - 115 in a matter of seconds.

Any particular Windows settings, or otherwise that can help lower this system demand specifically while resizing SAC window sizes?
(Settings that could allow SAC as is to continue running the following test mix at the 64 x.1 buffer settings - which run me between 6 & 7ms of total Input to Output latency at either 44.1 or 48k sample rates. In my experience musicians mentally fight the noticeable latency at 128 buffer settings. Under 7ms I don't hear complaints or comments.):



24 Stereo ch., ea. with all EQ, Low Cut, Gate, Dynamics and one Aux Send going to a Return channel (FreeverbToo w/ Stereo Expander) 4 St. Outs,
6 monitor mixes all getting their signal post FOH EQ & Dynamics, lightening load and system complexity, all using all 24 stereo In channnels, 1 St. out,
Studio Graphic Equalizer & Levelizer FX on all outputs


(I almost always have mostly mono mixes under 24 channels, but try to test above and beyond what I expect to need.)

Current Question again:
Any particular Windows settings, or otherwise that can help lower this system demand specifically while resizing SAC window sizes?

Thanks for all the replied comments guys, you got me to dig further and am learning how to lighten the Windows 10 system load better now.

[cgrafx]

This morning I rebooted the system after making all my changes: uninstalls, disabling, etc. listed in an above post with referenced info sources. The system now boots and settles down to 43 process (44 with task manager). SAC says it is running with only the Force RealTime Priority Class checked at 34-36% Load, Task Manager says 22% CPU, 33% Memory

I left the system on all night and it did not slip any buffers. That is good, but I noticed as soon as I tried to resize the main SAC window to view the Task manager beside it, the buffers slipped and were audible the entire time I was adjusting the size - 115 in a matter of seconds.

Any particular Windows settings, or otherwise that can help lower this system demand specifically while resizing SAC window sizes?
(Settings that could allow SAC as is to continue running the following test mix at the 64 x.1 buffer settings - which run me between 6 & 7ms of total Input to Output latency at either 44.1 or 48k sample rates. In my experience musicians mentally fight the noticeable latency at 128 buffer settings. Under 7ms I don't hear complaints or comments.):



24 Stereo ch., ea. with all EQ, Low Cut, Gate, Dynamics and one Aux Send going to a Return channel (FreeverbToo w/ Stereo Expander) 4 St. Outs,
6 monitor mixes all getting their signal post FOH EQ & Dynamics, lightening load and system complexity, all using all 24 stereo In channnels, 1 St. out,
Studio Graphic Equalizer & Levelizer FX on all outputs


(I almost always have mostly mono mixes under 24 channels, but try to test above and beyond what I expect to need.)

Current Question again:
Any particular Windows settings, or otherwise that can help lower this system demand specifically while resizing SAC window sizes?

Thanks for all the replied comments guys, you got me to dig further and am learning how to lighten the Windows 10 system load better now.


The task manager will almost always slip buffers. You can't check buffer slips with it running.

[mr_es335]

Philip,

The task manager will almost always slip buffers. You can't check buffer slips with it running....this is so true!

[Nathan P]

In my experience over the last 5 years, on my stable enough SAC systems, the task manager usually only causes 3-6 slipped buffers when it starts and possibly when it is closed. Once Task Manager is running, if I refresh LIVE in SAC, I don't see any slipped buffers after that. That is what I've been seeing in my test on most of my usable systems as a norm' and is true on for the last + or - 24 hrs. of tests on the system I've discussed in this thread.

[Bob L]

If you use the RealTime Priority option in SAC, the task manager should not cause slipped buffers in XP because its priority is less than that... although in Win 7, 8 and 10, the priority rating is mostly ignored so you might see some slipped buffers when it starts and runs as it steps on the SAC processing loop threads.

Bob L

[Naturally Digital]

Current Question again:
Any particular Windows settings, or otherwise that can help lower this system demand specifically while resizing SAC window sizes?

Thanks for all the replied comments guys, you got me to dig further and am learning how to lighten the Windows 10 system load better now.Likely video card related. I know very little about Win10 but look for display gloss/effects you can disable. If there is such a thing as 'show window contents while dragging', you can try disabling that one. Look for any fancy visual stuff you can disable.

In case you haven't checked it out, you might add this one to your reading list: http://www.blackviper.com/service-configurations/black-vipers-windows-10-service-configurations/
(http://www.blackviper.com/service-configurations/black-vipers-windows-10-service-configurations/)
Note that anything I'm going to suggest assumes this machine will never see the internet.

[Bob L]

Follow my Win 8 tweaks in the manual or helpfile... Win 10 is very similar.

Bob L

[Nathan P]

If there is such a thing as 'show window contents while dragging', you can try disabling that one.

That option was one of the Windows Tweak options I went back & I deliberately enabled for another program. Unchecking that option in "Adjust the appearance and performance of Windows" settings fixed that resizing causes slipped buffers issue completely. (For others, you can search by Start in Windows 10 for "performance" and it comes up first in my Windows 10 - internet searching is disabled on my system.) It makes perfect sense that this applied directly to the re-sizing window issue. I totally forgot I re-enabled it at some point.)

Thanks again guys, you were right on!