Low performance on new PC

Hello everyone

I’ve just invested in a new PC, and while it handles everything like a dream it’s slower than a raspberry pi when I try to make music on it. This code snippet makes it fall behind in time in less than a minute.

use_bpm 120
live_loop :main do
  64.times do
    synth :tb303, cutoff: 60, release: 0.125, note: (chord :c3, :minor).choose
    sample :bd_tek if (spread 1,4).look
    sample :bd_zome if (spread 3,16).look or (spread 7,16).look
    synth :beep, note: (chord :c6, :minor).look, release: 0.125, amp: 0.2
    sample :elec_tick
    sleep 0.25

My substantially slower laptop can run this without problems, as could my old pc. The only major difference is the new hardware, which includes an AMD cpu (i usually stick to Intel). Drivers check out as well. Where can I go from here?

Hi @chris.krakou, not sure if I can be of any help, but probably for all good to know at least:

  • which SP version
  • OS
  • internal or external soundcard

There can be more but this is what I can think of right now

Hi Martin.

Good Point. I’m using the latest Sonic Pi 3.2.2. I’m running Windows 10 Home from a fresh install. I’m using the onboard sound card, and I have installed the Realtek HD audio drivers from the manufacturers homepage.

On a different note, do you know where I can find the log files? in case they reveal something.

Hi Chris,

I don’t use Windows but my notes say the following (without warranty :wink: ):


hi @chris.krakou… AMD CPUs are still a hotly debated topic in the world of music production. Although AMD compatibility has dramatically improved over the years, I’ve seen performance and compatibility issues when using AMD processors with some DAWs(digital audio workstations) and VSTs(music production plugins i.e. reverb, compression, EQ, etc…).

Here is a brief video that covers this in more detail…
“AMD or Intel for music production?” https://youtu.be/Pfbt3-qOwro

I’m in the process of having a new PC built specifically for audio production and have been debating whether to go with the AMD Ryzen 9 3900X CPU or to wait for the Intel Comet Lake CPUs just being released. The deciding factor for me to choose Intel was the rare/occasional AMD compatibility/latency issues when it comes to audio production.

One thing that might help would be to install the ASIO audio driver for Windows. This will dramatically improve performance and reduce latency when doing any kind of audio production. I use the ASIO driver when I’m not plugged into an audio interface i.e. to work on my laptop with headphones.

Here is a link to the ASIO driver if you’d like to try it out… http://www.asio4all.org/

I don’t know if this is the reason for the problem you’re having but… using the ASIO driver instead of the generic Windows audio driver will definitely improve your overall audio production performance.

Another thing to look at is to disable any “energy saving” preferences.

These typically work by getting the computer to “go to sleep” as much as possible. Whilst this might be an effective strategy when writing a word doc or surfing the web, it doesn’t work too well with music production.

I have installed the ASIO drivers for good measure, and looked over the power settings. Has anyone experienced anything similar before? it just seems so bizarre.

@chris.krakou Hi Chris… this won’t solve your problem but out of curiosity, I just ran your code on an old laptop with very low specs (i3/6GB RAM), let it run for 5+ minutes and it ran in sync and in time without problems or any falling behind so the issue isn’t with the code.

If this was running well on your other laptop/PC and they had Intel processors, this could be one of the rare instances where the AMD CPU is the issue and why using AMD is still a concern for some in music/audio production.

Out of curiosity I tried running it on my Windows 10 AMD based desktop and it got out of sync within seconds. (Sonic Pi 3.2.2 / Windows 10 Insider build 19635 / Ryzen 5 2600 / 16 GB RAM)

I tried running this on a Windows 10 Intel laptop, and it quickly got out of sync, so it looks like it’s not limited to AMD.
It almost immediately started printing “Timing warning: running slightly behind…”, then after about 2.5 seconds started printing “Timing error: can’t keep up…”, and then around 5.5 seconds died with Thread death / Timing Exception.
This is on Windows 10 Enterprise 2004 build 19041.264 with an Intel Core i7-6820HQ CPU and 16 GB of RAM.

One thing to try is to increase the priority of the scsynth.exe process using the windows task manager.

@emlyn, that’s odd. I actually did have some trouble initially after installing where my windows install thought it was an Enterprise install rather than a Home install. I fixed it with a soft reinstall, but it might be worth a shot wiping the thing and starting over. Also good to know that it could be something other than the brand spanking new pc I bought.

@samaaron I tried to set the priority to realtime, and it didn’t help.

I also tried changing the priority to realtime, and it didn’t make a noticeable difference.
Adding a “use_debug false” at the top helped a bit, it then lasted around 10 seconds.

Hi Chris
Tried the code on an HP Pavilion with intel i5-825OU 1.6GHz cpu and 8Gb ram. running Windows 10 Home. No problems. Still going strong after 10 mins. Using SP 3.2.2

Also, try increasing the priority of the ruby.exe process…

I’m beginning to think that the issue might be related to the windows version. @emlyn and @SRSabu were both running non-Home versions of Windows, and mine was updated / reconfigured to Enterprise by mistake. I think I will do a complete re-install tonight and see what happens. It’s a bother, but it might work.

Just sharing my experience , running

  • Win10 PRO (Insider Slow Ring)
  • AMD Ryzen 5 2600
  • 48GB RAM
  • power plan makes no difference

and your snippet starts to slow down right after starting and dies after ~6sec

Wow, that’s crazy! Clearly the CPU or the operating system are doing things to interfere with the timing.

I wonder what we can do to alleviate this. Do you still get issues if you increase the priority of the ruby process?

ruby.exe process running with “normal: 8” priority:

  • with use_debug true => it dies ~6sec
  • with use_debug false => it dies ~10sec

ruby.exe process running with “high: 13” or “realtime:24” priority:

  • with use_debug true => dies ~6sec
  • with use_debug false => dies ~11sec

  • changing priority of sonic-pi.exe seems to have no effect (together with ruby.exe or alone)
  • ruby.exe is not using more than 0.6% CPU during this tests

must be something “under the hood” of thread management :confused:

Ruby’s threads are not normal threads, they’re so-called green-threads which means that they just use a single OS thread.

I’d be surprised if it was something to do with the Ruby thread system - especially given that things work perfectly well on a variety of operating systems and much lower powered hardware.

My guess is that the OS scheduler isn’t yielding to the Ruby process often enough to meet the timing requirements.

It would certainly be interesting to get to the bottom of things though.