Jump to content

Jim Roseberry

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Jim Roseberry

  1. Pay close attention at 14:47 Instruction Per Clock is faster on the 3900x But... (the devil is in the details) The highest Turbo speed is 4.6GHz/4.5GHz... and note that it can't be run across all cores. @14:22 "Okay, but JF, IPS is better on the 3900x... why is the 3700x (same core count and thread count as the 9900k) losing in many of the tests?" @14:33 You'll hear the exact thing I've said above. "Clock-Speed" @14:46 "Intel is still superior in the All Core Clock-Speed. To actually best Intel, AMD has to get clock-speed higher. The fact that 3900x/3700x can't run all cores at full Turbo Speed is both disappointing/telling. That means there's little to no over-clocking headroom (no means of closing the clock-speed gap). The 9900k can easily run all 8 cores at 5GHz. Idle temps in the 30's with quality air cooling. If I'm building a new DAW, why would I choose a 3700x over the 9900k? It's $50 less for a slower CPU (especially scenarios that aren't heavily multi-threaded) No Thunderbolt-3 (unless you pay ~$1000 for the motherboard) Apps not fully optimized for AMD CPUs Had the clock-speed been 5GHz across all cores, it would be a whole lot more exciting (especially with the 3900x).
  2. The 9900k doesn't run particularly hot. (Not like socket 2066 where you're forced to use a large water-cooler). You need robust air-cooling. Nothing at all to worry about... Near dead-silent Multi-threading is made use of in DAWs... but not all processes can be multi-threaded (as I mentioned above). In a perfect world, you want highest available clock-speed... and the highest number of cores you can get. Right now, the 9900k (IMO) is the sweetest spot price/performance wise. Precisely because you can have 8-cores (16 processing threads) all locked at super high clock-speed. At the risk of repeating, to best it... you're talking high-end (not bottom end) socket 2066 i9 (significantly more expensive). When it comes to heavily multi-threaded scenarios, you've got twice the number of processing threads (vs the 9700k).
  3. If you're going to go for the i9-9900, you should just go ahead and get the i9-9900k version. With proper configuration, all 8 cores (16 processing threads) can be locked at 5GHz. With a quality air-cooler, it will do the above while running near dead-silent. When choosing a CPU for DAW purposes, clock-speed is the single most important factor. Having more cores is beneficial... but not at the expense of significant clock-speed. Not all processes in a DAW can be heavily multi-threaded. Playing thru an AmpSim plugin at 96k using a 32-sample ASIO buffer size doesn't lend itself to being heavily multi-threaded. Some plugins like UVI's Falcon will only use a single core. Also note that core performance doesn't scale 1:1. IOW, Doubling the number of cores doesn't double performance. What you absolutely don't want to do is choose a CPU that has more cores... but significantly slower clock-speed. This is why Xeon CPUs are often a bad choice for a DAW. They have more cores... but (typically) significantly slower clock-speed. This results in a significant performance hit (compared to standard CPUs). Right now, for the reasons mentioned above, the i9-9900k is an excellent choice for most DAW users. You've got super high clock-speed (5GHz across all cores)... and 16 virtual cores (processing threads). To best the 9900k, you have to go high-end socket-2066 i9 (considerably more expensive). Ryzen is good for heavily multi-threaded applications (video rendering in particular). Where Ryzen falls short is with processes that can't be heavily multi-threaded. If you want/need Thunderbolt-3, Ryzen isn't practical. It's available on ultra high-end motherboards (~$1000 for the motherboard).
  4. To use the Eucon "ProTools Control" app on an iPad, the DAW itself need not be connected via WiFi. The DAW itself can be connected via hardwire (Ethernet). There's no performance hit (or worry about higher DPC Latency). The iPad (tablet) is the only device connected via WiFi. I've already tested this configuration. It works fine with Sonar/CbB... as well as all other Eucon enabled DAW applications (obviously including ProTools). Other than the time to actually configure all the options, it's pretty easy to set-up.
  5. There's a Eucon control surface plugin for CbB. Many folks don't know this, but you can actually use the (free) ProTools Control applet to control any (Eucon capable) DAW application. It will require some custom mapping/preparation... but it works great. I've thought about doing an instructional video on this topic.
  6. What's happening is that you're monitoring via hardware AND software... simultaneously. The software based monitoring is subject to latency (thus the slap-back). The hardware based monitoring is near zero latency. Combine the two (and depending on the amount of latency)... and you'll hear anything from flanging (combfiltering) all the way to slap-back sounding delay. This can happen with ANY audio interface and DAW software (not exclusive to your situation, audio interface, or version of Cakewalk/Sonar). You need to choose a single method of monitoring (either hardware or software - just not both simultaneously). If you monitor via the audio interface's onboard hardware, don't enable the Input Echo option in CbB/Sonar. If you monitor via software, make sure to mute/disable the audio interface's onboard monitoring (done via its control-panel app).
  7. Have you tried disabling the "Fast Bounce" option? Some plugins can't cope with it being enabled.
  8. The reason for the "audible glitches": The CPU is overheating... and the machine throttles down the speed (to avoid burning up the CPU). The reduced CPU speed causes the audible glitches.
  9. On a modern build, Hyper-Threading should be enabled.
  10. With off-the-shelf systems, the BIOS often doesn't expose all possible parameters. This is to keep less savvy users from fouling up their computers. The downside is that you don't have access to these parameters.
  11. I've raved about the Waves Scheps Omni Channel before... but just had to do so again. I've been working on some vocal tracks for a client's mix... where there are many plosives. Usually, I can isolate the plosive (as a separate clip) and use a High-Pass filter to remove it. In a few cases, the plosive is still objectionable (even after using a high-pass filter). I'd been using the Scheps Omni Channel's De-Esser a lot lately... to solve numerous issues (guitar string squeaks, standard de-essing, taming cymbals, etc). So... I figured I'd give the Omni Channel De-Esser (there's actually two of them) a shot at eliminating these problematic plosives. I set the frequency at 325Hz and engaged the first De-Esser. Problem solved. It was that easy. Ironically, I haven't been using the Sheps Omni Channel for standard mixing duty... but for specific problems it's been indispensable. The two "De-Essers" are capable of *far* more than standard de-essing. If you're dealing with similar issues, check it out.
  12. FWIW, The issue is the chipset on the Firewire controller. Over the past 25-30 years, I've seen many similar cases... and in almost all... the Firewire controller wasn't using a TI chipset. With a desktop, the solution would be to swap the Firewire controller for one that has a Texas Instruments chipset. With a laptop, you live with what it is (can't be swapped out). The issue has nothing to do with the MOTU or Sonar.
  13. Hi Pete, The latest Win10 install discs are version 1903. Installing on socket 1151/Z390 based machines (numerous different motherboards), with all available patches (thru Windows Update procedure), high DPC Latency persists. Installing from an older Win10 disc, there are no DPC Latency issues with v1803 or v1809. I've downloaded the KB4505903 fix from your link above... and will test to see if that resolves the issue. We appreciate your presence here on the forums!
  14. Hi Noel, I have not filed a feedback hub report. I'll do so ASAP.
  15. FWIW, Don't confuse DPC Latency with Audio Latency (two completely different things). You need low/consistent DPC Latency to effectively work at low audio latency settings.
  16. All popular DAW applications feature Automatic Plugin Delay Compensation (Automatic PDC). If a latent plugin is inserted *anywhere* in a project, all other audio is delayed by that amount (to maintain sample-accurate sync). There are two ways to work around the issue: While tracking, avoid latent plugins CbB (Sonar) has a global Automatic PDC bypass feature (enable this while tracking) Latency has but two sources (unless the DAW application itself uses additional buffering): Audio Interface Latent Plugins Some DAW applications use extra buffering (which adds additional latency). Ableton Live uses additional buffering (which can't be disabled). Cubase has "ASIO Guard" (which can be disabled) StudioOne has "Dropout Protection" (allows setting the additional buffer size from 128-samples up to 2048-samples - the green Z button bypasses the extra buffer)
  17. Though not directly related to your issue, Win10 build 1903 has been problematic on many current build machines. High DPC Latency...
  18. If you have a Yamaha keyboard (Montage, ModX), it can function as both a MIDI controller and audio interface. Yamaha owns Steinberg... and users their audio interface/driver technology. When you load the drivers for your Yamaha keyboard, the "Yamaha Steinberg USB Driver is installed". FWIW, I've seen a similar issue when a Windows update was (first) released. In the short-term, had to roll-back to the previous Windows build (everything then worked fine). Long-term, the issue was resolved.
  19. Any meta-data embedded with the kick sample? Does it happen with any kick sample... or just a particular sample/library? If you're talking loops, they're being time stretched/compressed to match the current project's tempo.
  20. I'd try deleting the Aud.ini file (stores information about audio settings)... then re-open CbB and see if the issue persists.
  21. Yeah, it's most likely a Via or Ricoh chipset Firewire controller.
  22. In the meantime, if you go to Preferences>Audio Driver>ASIO Panel... and change the ASIO buffer size (to another value and then back to what it was), this may clear the distortion without having to close CbB (Sonar).
  23. Are you using a TI chipset (Texas Instrument) Firewire controller? In almost every case regarding a problem with a Firewire audio interface, the end-user isn't using a TI chipset Firewire controller.
  24. Effects count - processor speed is the largest factor Track count - disk speed is the largest factor 1. Faster bouncing/freezing of tracks would be mostly down to CPU speed. 2. Faster loading of projects would be affected by disk speed and CPU speed. If you're dealing with large sample-libraries (that load particularly slow), you can put those on a M.2 Ultra SSD (sustain ~3500Mb/Sec). 3. Ability to run more tracks and plugins (as you can probably guess) is down to faster disk-speed and faster CPU. As a point of reference: Conventional HD sustains ~200Mb/Sec SATA SSD sustains ~540MB/Sec M.2 Ultra SSD (using 4 PCIe lanes) sustains ~3500Mb/Sec When it comes to CPU speed: Not all processes in a DAW can be multi-threaded. Playing/monitoring in realtime thru an AmpSim plugin at 96k using a 32-sample ASIO buffer size... isn't something that lends itself to being heavily multi-threaded Some plugins/instruments like UVI Falcon only use a single core This is why clock-speed is the single most critical factor when choosing a CPU for DAW purposes. Note that CPU core performance doesn't scale 1:1 IOW, Doubling the number of CPU cores doesn't double performance. Having more cores is beneficial... but not at the expense of significant clock-speed. This is why Xeon CPUs are typically a poor choice for DAW purposes. They have more cores... but often significantly slower clock-speed (resulting in significant performance hit). In a perfect scenario, you want highest available clock-speed... and the most cores you can get.
  • Create New...