• SONAR
  • x99 i7-5930k & sonar platinum thread balance
2015/06/04 13:03:39
javahut
just got an x99 i7-5930k 3.5 ghz, gigabyte ga-x99-soc champion board, 32gb corsair ddr4 2666 (running 2133), samsung ssd for os & audio, win7 x64, sonar x64, all x64 plugins. I'm running fixed oc @ 3.8ghz, all cores active & running, no turbo boost, no eist, no c settings, no ram xml active in bios.

I have mmc in sonar set to 2. but I seem to get the 1st thread noticeably more loaded than the other 11, and none of them are close to maxing out. yet I get audio engine drops with a relatively sane amount of tracks (<20), busses (10 or so), and plugins (20-30), and no vsti. buffer read/write @256, midi play buffer @ 2048.

granted, I'm using a few heavier plugins... like acustica nebula, but it is their local server version, which is supposed to be heavily optimized, running their core6 version, vstgui4, sse optimized.

it just seems like this pc should be able to load up the sonar cores, and running at least half core load for each thread with ease. but the audio engine is dropping off adding any more plugins, and with what looks like relatively little loading of the cores.

any ideas?
2015/06/04 13:15:43
Wookiee
Just as a matter of interest what audio interface are you using?
2015/06/04 13:22:45
scook
Start removing plug-ins till you find the one(s) that are chewing up the first core.
2015/06/04 13:43:06
azslow3
In parallel processing there is obvious basic limitation: paralleled threads should be independent. For example 10 VSTi on 10 separate tracks can work in parallel. 2 FXes on one thread can not work in parallel with audio data for the same time, so first FX can work let say with data from the second beat while the second FX still processing the first beat, but they can not work with the same beat (replace "beat" by "buffer" to get real picture).
 
Some plug-ins and not "real time", they just need quite some data to start processing. CPU has no influence on that. If let say reverb/compressor wants to know several ms of audio in advance, round trip time can not be smaller than that time.
2015/06/04 14:45:27
bandso
2015/06/04 15:36:42
javahut
Thanks for all the replies.
 
I'm using RME FF800 with latest drivers, and 1394b 800 connection to a TI PCIe card.
 
Thing is, I did start removing plugins one by one. But it really seemed no single plugin made a huge amount of difference. The difference was only gradual until finally down to almost none... and there's little processing going on in any of the threads. Still, the first has the most processing indicating.
 
It seems like I remember with my last system... once I set the MMCS (or whatever it's called) to 2... where the main processing thread gets a helper thread... that I could almost see all of the threads working hard... but the first thread had a little more going on AND, something like the 7th thread seemed to be kinda matching the 1st in amount of proccessing... and they were all working at a fairly high rate.
 
That system was basically the same except it was a i7-980x 3.3 Ghz I had running at 3.6, 24Gig DDR3. At some point it kinda developed the same problem I'm having now, where most of the processing seemed to move back to the first thread and I started having audio engine drops (when there had been none for the longest time). I had intended just to reinstall from scratch, as I thought maybe I had a lotta junk accumulated on the system over time. But I thought, if I'm going to that much trouble, I should make it an upgrade at the same time, since the 980x is getting a little long in the tooth. And running only x64 plugins would probably help. But once I got the new system up and running... not ALOT of difference. I even had 2 PowerCore PCI cards running in the old system, that I didn't use for much except Brickwall, VSS3, DVR2, MD3. Now that's gone with this x99 board.
 
Thanks for the suggestions so far. I'll check out that thread mentioned above. If anyone has any more, please don't hesitate...
2015/06/04 15:45:11
scook
So did you verify ThreadSchedulingModel = 2 in AUD.ini on this machine? Usually SONAR config will get it right but it is worth verifying.
2015/06/04 16:47:22
javahut
Yes, ThreadSchedulingModel = 2 is set (I wish it wasn't so that could be the problem  ). Was kinda hoping someone would jump in and say "oh, there's a ThreadSchedulingModel 3 for X99 that launches 'em into uber-thread balance mode... it's just not in the manual yet"  . 
2015/06/04 19:09:44
jimkleban
I was having a similar issue and I limited the thread count to 2 less than the total threads available with my CPU (another .ini variable) in which my theory was to  leave 2 threads for the OS and other system overhead.  I have 12 threads with a 6 core processor but only use 10 threads for SONAR.
 
Don't know if it will help but it is worth a try.  Sorry I don't remember the exact variable name but it is quite specific to what it will do.
 
Jim
2015/06/04 19:40:40
CedricM
Modern processors are rarely the problem. For music I would definitely not overclock the processor.
Even for games it rarely makes sense nowadays.
 
I would then increase the audio interface buffers when you are not recording music.
 
Last, it's perfectly normal that one thread is more used that the other. Even if Sonar was as close to possible to share the work evenly, it can't control the quality of vst/i's multitasking and the OS has many things to do too.
 
 
 
 
© 2024 APG vNext Commercial Version 5.1

Use My Existing Forum Account

Use My Social Media Account