Crackling sound when using samples intensively


I’m trying to create a piece based mostly on samples. For the moment, I only have two layers running:
— a drumkit composed of short sound files (1-3 secs) playing at 130bpm, every 0.125 beat.
— a drony content composed of long slow-attack samples, playing at 130bpm, every 2 beats.

On the top of the cake, I have a very simple live_loop randomly picking notes from the C# major scale, every 0.25 beat at 130bpm.

I’m experiencing heavy audio crackling and general slow-down of the music, and everything is slowly drifting towards an end in horrible crackling noises. This is not the first time that I experience this kind of behavior, as my pieces are very often based on intensive sample manipulations.

I think that this has something to do with the way Sonic-Pi is handling samples, and with memory allocation of some sort. Is there a way to overpass these limitations? I’ve searched in the documentation but I wasn’t able to find anything about that.

I’ve tried multiple setups, tried closing every other application running concurrently with Sonic-Pi.

I’m running Sonic-Pi 3.1.0-dev on a MacBook Air (Mojave).

Thanks !

Simplest test: Post your code and samples, see if
it crackles for other people, diagnose from there.


I’m using lots and lots of custom samples. I’ll try to make a vanilla version. But I think that my question is more general than specific to my particular case. I wonder what could be done technically to run Sonic-Pi better on standard non-raspberry devices.

For those who still want to see my code:


with_fx :reverb, room: 1, damp: 0.1 do
  live_loop :b, sync: :a do ; tick ; use_real_time ; use_sched_ahead_time 0
    ten = (ring 1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
    twenty = (ring 11, 12, 13, 14, 15, 16, 17, 18, 19, 20)
    thirty = (ring 21, 22, 23, 24, 25, 26, 27, 28, 29, 30)
    forty = (ring 31, 32, 33, 34, 35, 36, 37, 38, 39, 40)
    fifty = (ring 41, 42, 43, 44, 45, 46, 47, 48, 49, 50)
    sample scrap, [fifty].choose.look, amp: 0.4 if bools(1, (knit 1, 12, 0, 8).look).look
    sleep 0.125
end ; end


with_fx :hpf, cutoff: 60 do
  with_fx :reverb, room: 1, damp: 0.1 do
    live_loop :gong_church, sync: :a do ; tick ; use_real_time ; use_sched_ahead_time 0
      sample qrt, amp: 0.4, rate: [0.2, -0.2].choose * 1.5 * 2, attack: 2, release: 4
      sample qrt, amp: 0.4, rate: [0.2, -0.2].choose * 2.5 * 2, attack: 2, release: 4
      with_fx :reverb, room: 1, damp: 0.1 do ; sample gong, "gong", 2, rate: (knit 0.2, 4, -0.6, 4).look if bools(1, 0, 0, 0).look ; end
      sample gong, "gong", 1, rate: (ring 0.6, 0.8).look, amp: 4 if bools(1, 0, 1, 0).look # GONG SIMPLE
      sleep 2
end ; end ; end

Nothing too fancy, just a regular beat. My live_loop :a is acting as a regular metronome.

Can’t test it out myself right at the moment, but does removing the gong (and enclosing reverb FX) into its own live_loop improve things at all?

The preceding structure I posted is a compromise solution between having the sound I want to hear and saving CPU by placing a first reverb layer outside the loop. During the past few days, I remarked that using this technique can help me to build complex sample layers without having to deal with the Sonic-Pi crackling too much.

However, I can’t take too much freedom and improvise because I never know when I’ll reach the amount of complexity that starts overloading Sonic-Pi and that starts the crackling. I believe that there is something that can be done, maybe on the sound engine side, to improve the situation.

One improvement I can imagine would be to create a mechanism that kills automatically the last sample played / the last effect wrap that caused the overloading. Adding more and more would not cause the crackling, and the improviser would still be able to understand that he overpassed the limitations of the sound engine and must find something else to do.

Maybe I’m completely wrong about how Sonic-Pi is handling such things internally, I don’t know.

Hi @Bubo,

I do not have a solution for your issues. Rather I am also constantly reaching the limits of my hardware. Having said that: I am pretty sure that Sam has done everything to achieve the best performance possible as the first version of Sonic Pi was supposed to run on a Rasberry Pi. You might want to have a look at a thread I started.

Crackling sound, I am sure you know that, indicats that you are having Xruns, which is caused either by your soundcard and/or your CPU being not able to process the audio data in time.

  • Are you using an external audio interface? That is an obvious way to improve your system’s performance.
  • At least for linux (running the Jack Audio Server) it is recommended to deactivate Wifi because this can cause Xruns as well (the reason is: you need a system which works more or less in real time so any system activity, which is not necessary for your audio or the general os activity should be suspended)
  • I did some testing (and a live performance) where I used external plugins and Carla (e. g. a reverb) which can be a better solution than running effects within SP (another reason might be, that you want to use effects or need certain characteristics of effects you currently do not find in SP)

At some point you will definitely run into performance issues (well, you did already :wink: ), which has not neccessarily to do with Sonic Pi as such but the fact that processing audio needs time and resources depending on the complexity of what you are trying to do. At a certain point this would also be the case with Ableton or some other DAW.

At the moment I am also looking for a solution because I would like to have much more room (performance-wise) for more complexity in my tracks and/or my live coding. E. g. I just can’t imagine to run some visualization software (like Visor) because I need the resources of my laptop for the music rather than limiting what I can do musically by some additional software running. Probably I will have to buy faster hardware…


I am using an audio interface. Basically, I think I’m running into troubles because I try to compose for other live-coders who didn’t share the same configuration as me. They don’t have all the software synthesizers or DAW that I have, and by consequence, I’m forced to do as much as I can inside Sonic-Pi.

I don’t really have any issue with my solo performances, because I’m always trying to process the audio outside of Sonic-Pi (Max/Msp, Ableton, hardware synthesizers).

I will try to find new ways to optimise my code, but I’m always really near the limitations of the software. It might also be a good thing creatively, because it forces me to be more effective with less elements.