Windows 10 + Sonar + Scope ASIO Hiccups

An area for people to discuss Scope related problems, issues, etc.

Moderators: valis, garyb

Post Reply
al_bot
Posts: 36
Joined: Sun Dec 25, 2016 2:14 pm
Location: USA

Windows 10 + Sonar + Scope ASIO Hiccups

Post by al_bot »

Hello All,

I've been building a "new" setup configured as such: Win 10 64bit + 1st Gen i7 + Cakewalk Sonar 64bit + Pulsar 2 Scope 5.1 + SSD
I've followed the scope 5.1 setup instructions and disabled speedstep etc, set power mgmt to high performance, turned off wifi.

When using ASIO: I still get audio hiccups randomly, no cracks/pops. I can record scope inputs fine, as long as there's no hiccup.
When using WDM: It plays back perfectly, but I cannot record using Scope inputs, the audio is filled with static/noize/feedback.

I'm baffled as I never had these problems on Win 7 - 32bit with Sonar and Scope 5.1 using ASIO.

Any suggestions on how to avoid these problems in Sonar with either ASIO or WDM Scope drivers?

I wanted to utilize 64bit to environment to take advantage of some newer plugins and such.

Thanks!
User avatar
garyb
Moderator
Posts: 23248
Joined: Sun Apr 15, 2001 4:00 pm
Location: ghetto by the sea

Re: Windows 10 + Sonar + Scope ASIO Hiccups

Post by garyb »

ASIO should be click-free.

since you say you set power management to "high performance", i suspect you have missed something. setting power to high performance is not a suggested setting.

hyperthreading is off?

what is sharing an irq with the Scope card(s)?

are you sure you've followed these instructions?:
http://forums.scopeusers.com/viewtopic.php?f=3&t=31345
the instructions mainly refer to win7, but win10 is pretty much the same.

it's true that the wave drivers don't record in 64bit.
al_bot
Posts: 36
Joined: Sun Dec 25, 2016 2:14 pm
Location: USA

Re: Windows 10 + Sonar + Scope ASIO Hiccups

Post by al_bot »

Thanks Gary! yeah, I'm going through the list again. sadly my bios doesn't seem to have a lot of those options. for ASIO, the pops and clicks have been eliminated. I'm left with just random stuttering now and then. might be environment or something. still investigating...
User avatar
garyb
Moderator
Posts: 23248
Joined: Sun Apr 15, 2001 4:00 pm
Location: ghetto by the sea

Re: Windows 10 + Sonar + Scope ASIO Hiccups

Post by garyb »

stuttering?

the computer is definitely running out of resources. something in the backround? a plugin in Sonar?

what version of Sonar?
what samplerate and ulli setting?
what are the exact specs of the computer?
what else might be running?
virus?

btw- there's no need to disable wireless, unless it's because of an irq issue.

what is sharing an irq with the card?
al_bot
Posts: 36
Joined: Sun Dec 25, 2016 2:14 pm
Location: USA

Re: Windows 10 + Sonar + Scope ASIO Hiccups

Post by al_bot »

yeah, slight stuttering/sound distortion like a slight audio skip. I think it might be mostly fixed now. maybe i was hearing things last night?
it seems a lot better today.

Latest June/July update of Sonar Professional

Scope Sample rate was 44.1 and ulli at 13 ms (2nd to last option)

IRQ 16 had 4 devices: Scope, Nvida Graphics Card, USB thingy, and another USB related item i think. couldn't change any of the IRQs and no errors on the each of the devices.

I did read somewhere about nvidia drivers messing with the pc so I re-loaded the latest Nvidia drivers with a custom install and Skipped the following: HD Audio, physx, 3d vision, nivdia experience. Only installed the graphic driver. Also set the graphic options to visual performance.

virus scanner: windows defender

in Sonar Preferences I made sure the following items were UNCHECKED:
-Share Drivers with Other Programs
-64 bit audio precision
-Multiprocessing Engine (baffled, thought things would work better with it enabled)
-Use MMCSS
-Always Open All Devices

And changed the Sonar AUD.ini Config File: added ThreadSchedulingModel = 2

For the plugins, i think the random free vst i was testing may have also been causing trouble.
Now just using plugins from Korg Legacy Collection 64bit, Image-line's Harmor 64bit, and ADM's Drum Machine 64bit.
Things seem a lot better.

CPU is at 5-8% usage
Ram 8 gig and 19% used
SSD: SanDisk Ultra II 250 gb

Gonna try to write some random tunes and see if anything else happens.

Thx!
User avatar
garyb
Moderator
Posts: 23248
Joined: Sun Apr 15, 2001 4:00 pm
Location: ghetto by the sea

Re: Windows 10 + Sonar + Scope ASIO Hiccups

Post by garyb »

my pleasure, it seems like things are working now.

you don't need all that extra graphics stuff.

by the way, it's not about irq errors or conflicts. the system can report "no conflicts" and there can still be an irq issue. usually, it's "chatty" devices like usb that make problems. open system information, go to hardware resources/conflicts\sharing and tell me what, if anything, is sharing an irq with the Scope card.
fidox
Posts: 804
Joined: Sun Aug 17, 2003 4:00 pm
Location: Slovenia
Contact:

Re: Windows 10 + Sonar + Scope ASIO Hiccups

Post by fidox »

Do you use onboard graphic (processor graphic) or do you have separate pci-e graphic card installed ?

I was getting similar problems while i was using onboard graphic.
al_bot
Posts: 36
Joined: Sun Dec 25, 2016 2:14 pm
Location: USA

Re: Windows 10 + Sonar + Scope ASIO Hiccups

Post by al_bot »

I was using the pci-e video card. Wanted to do a dual monitor setup in the future.
Was using this guy: https://www.amazon.com/EVGA-GeForce-102 ... ga+8400+gs
needed a single slot video card as the pcie slot was right above the pci slot.
PaulSh
Posts: 32
Joined: Thu Sep 12, 2002 4:00 pm

Re: Windows 10 + Sonar + Scope ASIO Hiccups

Post by PaulSh »

A bit late into this one, but I don't come here all that often these days.

I just wanted to point out that, according to Cakewalk, Sonar should be fine with hyperthreading enabled as from version 3 onwards. I'm using the latest Sonar Platinum and have no problems when hyperthreading is enabled.
User avatar
garyb
Moderator
Posts: 23248
Joined: Sun Apr 15, 2001 4:00 pm
Location: ghetto by the sea

Re: Windows 10 + Sonar + Scope ASIO Hiccups

Post by garyb »

no, ht should be OFF. it has nothing to do with Sonar. ht only helps offline processes. it takes REAL cores to process virtual cores. you can't get something for nothing. in a realtime system, ht will make most processes late, which means lost data and clicks and pops. if your use allows ht without problems, great!
PaulSh
Posts: 32
Joined: Thu Sep 12, 2002 4:00 pm

Re: Windows 10 + Sonar + Scope ASIO Hiccups

Post by PaulSh »

Well, garyb, after 14 years of sterling service, my Pulsar board has finally died and it's time to move on so I guess I won't be coming here again. I didn't want my last post to be a big "No, you're wrong" type of thing because I know how much you've helped me and countless other people over the years, and I didn't want to repay that with a riposte rather than a thank you. But you've made a number of statements, and as someone who has been programming PCs professionally ever since there was such a thing as a PC, I couldn't let some of them go unchallenged. Bear in mind that much of the information floating around about ht is dated, and Intel and MS have made significant improvements to the way it's handled over the years. But let's just take a step back and look at ht in general.

So, you start off with n physical cores, so once ht is enabled you have 2n virtual cores instead (not, as seems a common belief, n real cores and n virtual ones). Windows by and large just sees the number of cores as doubling, and so is able to schedule twice as many threads. And btw, there's nothing magic about 2 threads per core, it just depends on the CPU architecture - PowerPC runs 3 threads per core, and the Intel Xeon Phi runs 4 threads per core (which is insane when you have 60+ physical cores to start with). So what's in a core? It's basically a computer of its own, with a simple instruction set (the micro-ops or μops), an "OS" in ROM, various types of arithmetic processing units, several different types of RAM, and lots of I/O. Its main task is to fetch the complex x86 instructions (macro-ops), and break them down into μops which it queues up and executes. It will try every trick in the book to make sure it's not sat there doing nothing - for example, it works out which μops don't depend on the results of others so it can execute 2 or more simultaneously, depending on which processing units they need, or it can even bring a μop forward right to the front in the queue if it sees there's an appropriate processing unit free and nothing else depends on the results. It will even try to guess the result of a conditional branch operation and fetch (and even start executing) macro instructions at the predicted branch target. But of course the processing resources are limited, and there may well be μops just stuck waiting to execute.

If it had a longer μop queue then it would have more to choose from and there would be more of a chance it could find one that it could execute. Intel went down that road with its Netburst architecture, but that was a dead end because the longer the queue, the more severe the time penalty for mis-predicting a branch, and so the performance gain is negated. With the Nehalem architecture, Intel did a radical redesign and allowed one core to process 2 execution threads. Each core can now have twice as many μops in its queue without doubling the penalty for a branch mis-prediction. A further refinement with Haswell and beyond was to segregate the μop queue between the 2 threads so that one of them wouldn't monopolize it to the detriment of the other. And occasionally Intel will throw another processing unit into the core to improve things yet further.

The best analogy I've seen is that of a carpenter. He has his tools, and at any one time he's using one or more of them, so maybe a clamp and a drill, or a bench and a saw. The problem here is that there are expensive tools sitting there unused, so what you do is you get another carpenter along and say they both have to share the same tools. While carpenter #1 is drilling, carpenter #2 can be sawing, and so you are making the best use of the resources. So if carpenter #1 is making a chair and #2 is making a bird table then this probably works pretty well as mostly they won't be needing the same tools at the same time. Where it may not work so well is if they're both making chairs and starting at the same time so they need the same tools in the same order, or maybe #1's chair is a rush job but you haven't told either of them and so he sometimes waits for tools that #2 is using because neither of them knows that #1 ought to be in a hurry.

Taking this back to CPUs and ht, if you have a lot of active threads all doing the same thing, like, oh, say they were all streaming audio, then ht may not be the best thing as they may end up all waiting for the same resources at the same time. Or if you had some really important threads, like, oh, say they were all streaming audio, then again ht may not be the best thing as they may end up having to wait for resources being used by some less important threads because it's only the OS that knows the thread priorities, not the cores. Time for a curveball, though. Even if you don't have ht enabled, don't think that your threads run uninterrupted on the same cores as Windows may well spread a single thread across the available cores. Say you have 4 physical cores and ht is off, and just run a single-threaded process. You may well see that even though the process is using 25% of your CPU, if you look at each individual core, there's not one running at 100% and the others idle, they are ALL running at 25%. So even if you're just making a single chair, there are 4 carpenters actually working on it in turns!

So how to fix this and make ht work the way your software needs it to? Many years ago, MS introduced the SetThreadAffinityMask and SetProcessAffinityMask OS calls. What these do is to specify which core(s), or virtual core(s) if ht is enabled, your process or thread is allowed to use. So if you don't want your thread smeared across different cores, ask for it to run on just one of them. If you have lots of threads all doing the same thing at the same time, ask for them to be allocated to virtual cores in a way that will minimise internal resource waits. Now we're ready for:
garyb wrote:it has nothing to do with Sonar
No, it has everything to do with Sonar, or whatever DAW you are using. That software should be using the affinity masks to mitigate the ht downsides and maximize the upsides. Or they could just chicken out and tell you to turn off ht (which is fine if you are a professional with dedicated music PCs). You can actually see that Sonar is using affinity masks because, at least on my PC with ht enabled, it is only using 7 of my 8 virtual cores most of the time. Why exactly it should be doing that I can't tell you because affinity masks are tweaky things and Cakewalk probably spent ages working out the best settings.
garyb wrote:ht only helps offline processes
No, ht can help with any process if used correctly because it's maximizing the use of processor resources.
garyb wrote:it takes REAL cores to process virtual cores.
True, but as far as Windows is concerned, your "real cores" are still pretty virtual because of the way it smears threads between them unless your software tells it not to.
garyb wrote:in a realtime system, ht will make most processes late, which means lost data and clicks and pops.
Windows has never been and will never be a realtime OS. I've worked with proper realtime OS like OS-9 and they are very, very different beasts than Windows. OS-9 doesn't even allow multiple cores, let alone ht. In a non-realtime OS supporting multiple cores like Windows you just have to make the best of a bad job, and that means not letting processor resources lie idle.

But now we come to the crux of it:
garyb wrote:... if your use allows ht without problems, great!
I'm glad I can end with something of yours that I can wholeheartedly agree with. If ht works in your setup then it works, otherwise it doesn't, whether it ought to or not.

So on that note, I bid you farewell and wish you (and everyone else here) all the best for the future.
User avatar
garyb
Moderator
Posts: 23248
Joined: Sun Apr 15, 2001 4:00 pm
Location: ghetto by the sea

Re: Windows 10 + Sonar + Scope ASIO Hiccups

Post by garyb »

hey, good for you! you've managed to hit and run.

for a soundcard, what you wrote is 100% correct, but the Scope card IS NOT a Windows soundcard, so things work a little differently. the audio processes are not necessarily happening in Windows and Windows doesn't necessarily know what is going on with the audio. the streams are simply presented to Windows and then passed to the app and vice versa. the Scope hardware really is realtime hardware and the computer never will be. if the streams are late, you get pops and clicks. i have yet to see a Scope(audio) system that actually runs faster(does more work) simply because HT is on, but use it as you wish.

of course, it's easier to just say that Scope doesn't use HT properly, which is true. Scope and HT are completely unrelated. any use of HT is after Scope. Scope doesn't actually run on the CPU, for the most part. Scope is merely a gui. i don't get why it's so important to you, but again, i'm not the arbiter of your needs. i'm a guy who is not impressed by computers. they are tools for audio manipulation for me ONLY. my only interest is simply practical. i don't care about theoretical gains, i only care about what can be run reliably. it is a fact that M$ and Intel(and AMD) don't do what they do because they are a bunch of philanthropists. i'm happy to use what they make, though.

anyway, the truth is more important than my feelings so don't feel bad about wanting to correct me. i know that you're gone and all, i know you wanted to drop a bomb and then leave the wasteland caused by your wisdom behind, but still...a Scope computer doesn't need HT and a Scope user will have fewer problems if HT is disabled.
dawman
Posts: 14368
Joined: Sun Jul 24, 2005 4:00 pm
Location: PROJECT WINDOW

Re: Windows 10 + Sonar + Scope ASIO Hiccups

Post by dawman »

I concur, and because Native Instruments recommends HT Off I don't use it on any apps.
I do however go for the very fastest single core performing CPU Ican get because 2 synths I use are Core locked.
4.4ghz is optimal, and at those rates hyperthreading really can't fit in the instruction pipeline without causing cache misses.

But I use a lean customized version of Bidule.
Post Reply