Jump to content

Pete Brown

  • Content Count

  • Joined

  • Last visited

Everything posted by Pete Brown

  1. Ok. I'll stand down on this for now. LMK how it goes. Pete
  2. Hi All Noel let me know about this issue. (Thanks @Noel Borthwick ) @Marcos Kleine which OS and version are you running? (If Windows 10, go to Settings->System->About to get that info). @Johnbee58 same Q for you. I'm curious to know why it works for you and not Marcos. Have you tried Noel's approach and found it to still work? Before I can get this in front of the team, I need to figure out if this is an issue that was always there vs. something new, so if anyone else can repro on older versions of Windows 10 and/or 8.x and/or 7, that would be incredibly helpful. To be frank, the GS wavetable synth isn't the best thing to use to make music with. It's in the OS mainly for compatibility, but the sounds are super dated and the latency is pretty high. Personally, I'd like to see it go away, but we have this thing about backwards compatibility. :) Pete
  3. Hi Jim Stock 1903 has an issue with kernel code that causes high DPC latency on some PCs. The updates available for it should include the kernel patch we released last month, including KB4505903 (which I believe is in another roll-up with a different KB number). If you still have high DPC latency after that (and rebooting), please do a trace per the blog post above, and provide the link to me. Note that tools that measure DPC latency aren't always accurate -- the team needs to hear the glitch in the audio that is recorded as part of the trace. Finally, a common cause of DPC spikes is power settings: both the PC and the video card. There are LOTS of variables here, but with nvidia GPUs, make sure to set it to prefer maximum performance: (NVIDIA control panel -> Manage 3D settings -> Global Settings). Folks on other forums have found that that setting alone appears to have a big impact in DPC latency. It's not something I've measured, myself. Pete
  4. Noel ping me about this thread. We released a fix for the ntoskrnl 1903 very high DPC latency issue late last month. Not all of these things make it into announcement posts, so follow me on Twitter if you want info earlier. If after installing that (or the roll-up that contains it), you still get high latency spikes, it's likely something else. Best way to diagnose that is to take a glitch trace and make us aware of it by sending me a link to the Feedback Hub entry. Instructions are on Matthew's blog. Make sure you can hear the glitch when taking the log/trace. Sometimes we get traces with no audio, and that doesn't help. :) https://matthewvaneerde.wordpress.com/2016/09/26/report-problems-with-logs-and-suggest-features-with-the-feedback-hub/
  5. Thanks. Pretty sure the FLS Checker VST simply has a hard-coded 128 in it. I assume, when you click "update", it has a loop that tries to allocate slots up to 128 and stops when it gets the error, and then just frees them all. That's my assumption anyway. Pete
  6. I've installed 18312 on my DAW PC. FWIW, I tried out the FLS Checker plugin, and it maxes out at 128. So DAWs all show 128 even after a ton of plugins have been added. To confirm the slot increase, I wrote a small C++ console app. It's running under the debugger here, so a few slots are taken. Results Code
  7. I didn't dig into it at all. I also haven't tried it in Cakewalk. I've seen others report it, and I had it happen with me in another DAW. Pete
  8. That's up to the individual. We just didn't think the OS should be making that decision for you. Pete
  9. There are some real subtleties to this. I figured it would be good to post a clarification. Most DAWs use between 20 and 40 FLS slots. Plugins typically use 1 to 45 slots themselves (with most using < 4). It's not about loading up 128 plugins, but loading up plugins that take up the remaining slots left after the DAW has its slots allocated. The VC runtime allocates a slot (the whole static linking thing), but code may allocate FLS slots for other, completely legitimate, reasons. Or the plugin may just have a whole lot of statically linked runtimes in its numerous sub components, using up slots and wasting memory by filling it with many copies of the same runtime code. You don't know which case it is unless you decompile the plugin code. Here are some numbers that folks put up in another forum (I have not personally confirmed them, but they look right): Steinberg Padshop - 1 Spectrasonics Trilian - 1 Waves (Waveshell) 2 Waves Codex - 2 UAD -2 Roland TR 808-2 dbx160 - 2 Slate VMR - 2 FXpansion BFD3 - 2 Korg Arp Odyssey - 3 Steinberg Dark Planet - 3 BX20 - 4 ATR102 - 4 Kontakt -4 Maschine-4 SSL E Legacy - 4 API 2500 - 4 EMT 140/250 - 4 Fairchild 670 MKII - 4 LA-2A Grey - 4 Arturia Arp 2600 v3 - 6 Arturia Buchla - 6 Arturia DX7 - 6 Synclavier - 7 CMI - 8 Analogue Lab3 45 I've also separately confirmed that iZotope Neutron uses 10 slots itself for the version I have (I'm a rev behind current, as I recall) So if the DAW uses, say, 30 slots, and you also have Analog Lab 3 loaded, and Neutron, you end up 85 of your 128 slots taken up. It's not at all hard to hit that limit this way. Note that freezing or disabling tracks doesn't change this count. It's about code loaded into the process. Also note that adding and removing a bunch of different plugins in a session can also use up slots, as it appears the slots don't always go back to the pool. Not sure why there, and I haven't looked into it. The limit is per-process, not machine-wide. Solutions that host plugins in a separate process get their own 128 slots. The limit itself goes back to Windows Vista, and hasn't changed since then. Folks using Windows 7 have confirmed that the slot count is the same as on Windows 10. The fix itself, if all goes well, will be in the 19H1 release of Windows 10, in the first half of this calendar year. Pete
  • Create New...