Unable to start Sonic Pi version 4.6.0 on Windows 11 Version 24H2

[eviv-java]

On first start after installation from MSI installer I can see splash screen, and then alert screen appears, saying it has issues connecting to the Ruby server

Sonic Pi error log.txt

[ethancrawford]

@eviv-java - there are a handful of issues with this same series of error messages for v4.6 on Windows. Several of them have turned out to be Erlang requiring access to the network but being denied by the firewall. It's possible you are having the same or a similar problem.
See eg:
#3424
#3451
#3472

[kovariki]

I'm having the same exact issue:

Sonic Pi Error Message.txt

[Intoxinator]

Same issues for me. Runs on mac just fine.

[SuzanneLumi]

Same here

SonicPI_4.6.0_StartupIssue_Win10.txt

[Intoxinator]

Summary of findings and cross-platform patterns

• Symptom: GUI fails to complete boot and reports "Unable to connect to server / Ruby server" or "Could not boot Sonic Pi Server".
• Affected OSes: Windows (10/11), macOS (Sequoia / Ventura / M1/Intel), many Linux distributions (Debian, Ubuntu, Kali, Mint).
• Typical boot sequence failure points:
  1. GUI spawns Boot Daemon / Spider (Ruby) and waits for OSC/UDP handshakes.
  2. Repeated timeouts or socket recv/send errors (UDP/Tau comms) cause handshake to fail.
  3. SuperCollider (scsynth) sometimes starts successfully, but Tau/Ruby/Spider processes fail or exit; in other cases scsynth itself fails (JACK/ALSA/RT errors).
• Recurring low-level error messages seen in many reports:
  • "Error reading ports via Boot Daemon STDOUT"
  • "Unable to connect to tau (Promise timed out after 30 seconds.)"
  • UDP recv errors like "An existing connection was forcibly closed by the remote host" (Windows).
  • JACK / ALSA / RT scheduling errors on Linux: "Cannot lock down ... memory", "Cannot use real-time scheduling", sample-rate mismatches (48000 vs 44100).
  • Missing Ruby gems or native extensions on some Linux installs (e.g., rugged, wavefile).
  • Segfaults or crashes in Boot Daemon / Tau on some macOS runs.

Troubleshooting steps reported (grouped)

1. Quick checks (all platforms)

• Restart the machine, try launching again.
• Run Sonic Pi with elevated privileges (Administrator / sudo) to test permission/RT issues.
• Temporarily disable firewall / antivirus and test whether UDP/Erlang/Tau comms succeed (Windows).

2. Windows

• Add Sonic Pi and Erlang/Tau binaries to firewall/Windows Defender exceptions.
• Use the official stable release instead of an in-development build if you’re on a dev build.

3. macOS

• If Boot Daemon STDOUT read errors appear, check the packaged ruby daemon is executable and inspect Boot Daemon output directly (run the server binary manually to capture stdout).
• Check for segmentation faults in daemon/tau logs.

4. Linux (most common cause of scsynth failures)

• Ensure JACK is installed/configured and running, or configure ALSA appropriately.
• Grant realtime privileges or increase memlock limits for your user (ulimit, /etc/security/limits.d).
• Ensure system sample rate (ALSA/JACK) matches scsynth expectations (typically 44100 vs 48000).
• If scsynth fails with "Cannot lock down ... memory", set proper memlock limits or run scsynth without real-time scheduling when testing.
• Rebuild or install missing Ruby gems referenced in server logs (e.g., run gem pristine or install required gems).

5. Ruby / gems / Tau

• If logs show missing gems or "extensions not built", try rebuilding gems (gem pristine or reinstall) or use the provided packaged runtime.
• Verify Tau (Erlang) process starts and is not blocked by firewall or crashing.

What worked for some users

• On Windows: disabling firewall / adding exceptions or reverting to a stable release resolved the problem for a subset of users.
• On Linux: fixing JACK/RT privileges and sample-rate mismatches often allowed scsynth to boot.
• Rebuilding missing Ruby gems or using an installer that includes the required gems fixed cases where server failed due to missing Ruby dependencies.
• On macOS: inspecting Boot Daemon stdout and ensuring the packaged binaries are executable helped diagnose and resolve some failures.

[Intoxinator]

Ok, so I've just got it working.

I deleted the .sonic-pi directory in my home directory and it started!

Shut it down and started again - and it worked.

[Intoxinator]

Aaaaand... it has stopped again.

I observed that the spider service threw some form of error and the waiting for ruby server countdown ended prematurely. Then on the next start, startup failed with the same behaviour seen in this thread.