Live midi and audio latency reduction

Hi again,

I’ve been experimenting with use_real_time midi triggers and live_audio, but have been rather disappointed by the latency - it feels like several tens of ms. Does anybody have any advice for how to reduce latency? In DAWs, this would typically be accomplished by reducing buffer sizes etc., but I couldn’t find any configuration for this in Sonic Pi.

My set-up: Mac OS X Mavericks on a 2016 MBP, Apogee Element 88 audio interface connected via firewire, Roland Octapad + drum triggers as a midi controller.

I can get latency to acceptable levels (<10ms) in Logic Pro and the likes, I was really hoping to accomplish the same in Sonic Pi.

Thanks in advance,

Jonathan

You can compensate for delays by “turning back time” for everything else using the time_warp function, and encapsulating everything in a block. Messing around with this can probably eliminate the issues you’re having, if the delay is stable.

Hi @cozmic,

no specific help but some hints to dig deeper: I do not experience such latency under Linux. Especially not if I am using an external audio device (Focusrite). I assume you can get an acceptable latency also with OSX, in other words: I think up to a certain degree it is a configuration issue. There are others here on the forum who use OSX on a regular basis and who possibly can help with that. (By the way: as far as I know it is also possible to use Jack with OSX; might be a worthwhile try.)

I’m not entirely sure what you mean by “everything else”. For now, I am just triggering samples externally from a drum pad, and there is a discernible delay (Perhaps ~20ms) between my striking the pad, and my hearing the triggered sample. I am not generating any other notes - yet.

Perhaps your advice will come in useful when I try adding a click track - the next stage in my experiments.

I guess that’s exactly what I’m asking: how do I configure the audio buffer sizes used by Sonic Pi?

It is certainly not a driver/hardware issue: as I said, things are working fine in other OS X software.

I’m not sure what Jack would do, other than maybe adding more latency to the mix?

Hi,

unfortunately it’s not currently possible to edit the buffer sizes used by the underlying synthesis engine SuperCollider without directly editing the source code at this stage.

This is something I’m hoping to add to a future version via a config file.

If you’re interested and adventurous, the place to look for the config in the source is here: https://github.com/samaaron/sonic-pi/blob/master/app/server/ruby/lib/sonicpi/scsynthexternal.rb#L333

I am certainly adventurous - but struggling with the build scripts. Looks like build-osx-app expects a non-native version of bash? (I do wish Apple would ship a more recent version!)

You don’t actually need to build anything - just modify the matching file in your version of Sonic Pi’s app bundle. The full options to scsynth are here:

supercollider_synth  options:
   -v print the supercollider version and exit
   -u <udp-port-number>    a port number 0-65535
   -t <tcp-port-number>    a port number 0-65535
   -B <bind-to-address>    an IP address
   -c <number-of-control-bus-channels> (default 16384)
   -a <number-of-audio-bus-channels>   (default 1024)
   -i <number-of-input-bus-channels>   (default 8)
   -o <number-of-output-bus-channels>  (default 8)
   -z <block-size>                     (default 64)
   -Z <hardware-buffer-size>           (default 0)
   -S <hardware-sample-rate>           (default 0)
   -b <number-of-sample-buffers>       (default 1024)
   -n <max-number-of-nodes>            (default 1024)
   -d <max-number-of-synth-defs>       (default 1024)
   -m <real-time-memory-size>          (default 8192)
   -w <number-of-wire-buffers>         (default 64)
   -r <number-of-random-seeds>         (default 64)
   -D <load synthdefs? 1 or 0>         (default 1)
   -R <publish to Rendezvous? 1 or 0>  (default 1)
   -l <max-logins>                     (default 64)
          maximum number of named return addresses stored
          also maximum number of tcp connections accepted
   -p <session-password>
          When using TCP, the session password must be the first command sent.
          The default is no password.
          UDP ports never require passwords, so for security use TCP.
   -N <cmd-filename> <input-filename> <output-filename> <sample-rate> <header-format> <sample-format>
   -I <input-streams-enabled>
   -O <output-streams-enabled>
   -H <hardware-device-name>
   -V <verbosity>
          0 is normal behaviour.
          -1 suppresses informational messages.
          -2 suppresses informational and many error messages, as well as
             messages from Poll.
          The default is 0.
   -U <ugen-plugins-path>    a colon-separated list of paths
          if -U is specified, the standard paths are NOT searched for plugins.
   -P <restricted-path>    
          if specified, prevents file-accessing OSC commands from
          accessing files outside <restricted-path>.

To quit, send a 'quit' command via UDP or TCP, or press ctrl-C.

Thanks, Sam! I gave it a go yesterday, and reducing the buffer size certainly seems to help.

1 Like

Did it help reduce the latency to a level acceptable to you?

Hi Sam

I’m having similar limitations with Win 10. I’m reasonably capable programmer, but unfortunately don’t follow what to do here (more specifically where to make these adjustments) - any chance you could spend a moment to be a bit more specific?

Huge thanks for the work you’ve done by the way - found your Goto talk inspirational and echo your frustrations with the whole curriculum situation. We’ve decided to home school our two kids for this (and other) reasons, and the results have been fantastic. I now write code as part of my job - yet remember being frustrated with Basic back in the 80’s as I hit the ceiling and it didn’t “do” anything - so left programming for a decade until I entered engineering.

Keep up the good work…
Tim

Happy New Year !

… and a big Thank You! This is great information that just comes at the right time. I’m also struggling with latency in Windows 10. I’ll try to play with the buffer size, as I guess it might be much lower than what’s currently used.

Peter

Something else to play with on Windows is to switch to ASIO drivers :slight_smile: