Is anyone else experiencing noise issues with their external sound card when using the live_audio fn? I’ve tested on Echo Audiofire-8, Focusrite Saffire and Expert Sleepers ES-8. All similar issues arise with varying frequency. Thought i’d ask on here 
Hi @samconran,
Sorry you’re having issues. Are they specific to Sonic Pi or do you have similar issues with other audio apps?
Yes with Max Msp ADC object there is also an issue, but not as extreme. It happenes when there is a overload (when track is too hot and over red) it sounds on both like the clock looses its sync for a moment or that data is being mis-interpreted.
BTW, I’m assuming you’re running on macOS?
Unfortunately I’m not personally sure how to help - it sounds like a system-level issue. Perhaps someone like @Bohrbug might have some dark-knowledge which might shed some light on this matter?
Hi @samconran,
Could you please show your code you are using to use the live_audio fn ?
What O.S. are you using ?
Could you make a recording or screen capture of the noise you are hearing ?
I can have a go to try to find out what’s happening
1 Like
Thanks 
live_loop :chord do
x = (chord :cs4, :halfdiminished).reverse.tick
puts(x)
midi x, port:"sport_B"
sleep 0.125
end
1.times do
b = :a1
with_fx :record, buffer: b do
live_audio :foo
end
sleep 8
puts("no")
end
live_loop :e do
use_random_seed 101
sample buffer[:a1],amp:0.5,rate:(scale :cs5,:aeolian).pick(2).tick*-0.02
sleep 8
end
Sound example here on the pad: https://soundcloud.com/orbsasunder/26-9-2017-132820a/s-ylBbC
@samconran - I just edited your post to fix formatting. For code snippets you need three backticks on their own line to start and finish the snippet
@samconran to help speed things up, what’s the smallest amount of code needed to reproduce the issues you’re hearing?
For example, do you hear issues with:
live_audio :foo
Hey, thanks for the response! I am on OSX 10.11.6 incidentally, as I forgot to mention… I did not know of a way to set the buffer size of the hardware in Sonic-Pi, on Max (as I mentioned there were also some issues) I usually use as low as possible but I guess 256 in reality… Sample rate I am using 44.1k but I recall trying quite a few higher options and still had the same issues, annoyingly they are infrequent and occur somewhat randomly, but may have some connection with too hotter signal as mentioned, once its ‘freaked out’ it is more recurrent from that stage on. @samaaron, I will get back to you on that ‘as simple as possible’ tactic.
1 Like
Hi @samconran - you’re right, it’s not currently possible to set the hardware buffer size in Sonic Pi from the GUI - but it is possible by hacking the right file. If you head to /Applications/Sonic\ Pi.app/app/server/sonicpi/lib/sonicpi/scsynthexternal.rb and edit this line:
You can add the appropriate scsynth flags and restart the app. The supported flags are:
ERROR: There must be a -u and/or a -t options, or -N for nonrealtime.
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
-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.
2 Likes
What happens when you lower the volume of the source ? Does the control software of your Focusrite saffire show high levels of input coming in ?
@Bohrbug, sorry to ignore your most recent question but I think the issue is now fixed! The new bigger HW buffer size of 1024 makes a big difference so far. Thanks for your help and urgency Happy daze!
No Problem, your welcome. A buffer size of 1024 will give you substantial latency, so on that part, your set-up might be improved
1 Like
I agree with that notion but not sure what else is possible, there are still issues but they are less frequent, yet seem periodic. Also, have noticed that on the scope when the issue is happening you can see the the buffer frame size as it has sharp edges with in the waveform that eventually phase out. This is what makes me think that it is a very minor but significant clock issue… I have just tried down to 64 frame size (the lowest it will go and still boot the server on opening SP) and the issue is almost entirely present, ie. very frequently. A strange phenomena…
Hey folks just popping in here hoping since this discussion is kind of related someone might know how/where to set a different audio out on sonic-pi? I am on Raspberry and hoping to set the output to the Blokas “pisound” hat.
Sorry for invading --just hoping you all might have an answer
cheers
Patrick
Hi Patrick
I have pisound board running as default on my Pi3 with Sonic Pi.
I don’t have time right now, but will post details of my configuration for you , hopefully tomorrow afternoon.
Hi there, just wanted to bump this thread and also provide a audio sample of the issues mentioned in previous thread. I am using Sonic-Pi 3.1.0 and a FocusRite Saffire 6i6 usb soundcard, my Machine is Mac OSX 10.11.6 (El Cap) and this issue is relating to using the :sound_out fx - as before the glitches are infrequent but do not allow me to use Sonic Pi for anything requiring routing at this time which is fairly limiting. @bohbug, does this glitch sound familiar? As mentioned this is consistent over multiple soundcards.
https://drive.google.com/file/d/1GAxe4mvx55_jl7c7qAkZO9W2lHFi827x/view?usp=sharing
Does the time between these clicks correlate to the time of the live loop containing the :sound_out FX?
If you make the live loop spin round faster do the clicks also happen more frequently?
This is solved, the issue was the Soundcard. I’ve updated my setup to a MOTU Ultralite AVB. I had been experiencing issues with the (now un-supported) ECHO AudioFire-8 Laya and a Focustrite Saphire Pro 6i6. If that helps anyone.
Cheers @Bohrbug and @samaaron for the support on this mystery. 
happy daze.
1 Like