< Back to IRCAM Forum

Spat 5.2.8 + dropouts


I switched from Intel to M1 Pro in March 2022 (see config below) and installed Spat 5.2.7. I quickly noticed that my Max patch containing the Spat had dropouts, sound would stop et resume abruptly (maximum 1 second stops). More surprising is that dropouts not only happen in Max but also in all other running audio applications (Reaper, Live, Ircam TS2). I recently installed Spat 5.2.8 and, despite a strong improvement at this level, I still experience general dropouts form time to time (which is a problem for live performance). I tried to modify the scheduler’s settings in Max in many ways without success. I never had this kind of issue with my previous MacBookPros (Intel) and suspect it might be linked to the way Apple Silicon chips / Mac OS 12 deals with the distribution of audio and decides to interrupt the sound in case of CPU overload (with Intel chips sound wouldn’t stop, I would have clics in case of CPU overload). It is likely linked to the Spat/Max since I don’t have the issue with any other audio apps. My audio CPU readings in Spat/Max rarely exceed 20% and my laptop is pretty powerful, ex : I can read without any trouble more than 256 multichannel tracks simultaneously in Reaper.

Any idea what the problem could be ? Thanks for your help.



MacBook Pro 16” 2021 - Chip M1 Pro - RAM 32Gb - SSD 4To - Mac OS 12.3.1 - RME Fireface UFX

Max 8.3.2 - Spat 5.2.8 - Ableton Live 11.1.6 - Loopback 2.2.9 - Reaper 6.68

Hi François,

I have been using the M1 for quite some time now, and I have never experienced anything similar.
(and no one has reported similar issue)

  • Spat cannot interact with other (audio) applications such as Reaper, Live or TS2. The different process are totally isolated. So I dont see how this is related…
  • What kind of spat objects are you using in your patch ?
  • Most spat objects run perfectly smooth on M1. However, with the M1, Apple has changed something important in the way threads behave; so this can impact (the very few) spat objects using background threads, such as spat5.conv~ or spat5.spat~ with “/parallel” feature. For these objects, it is possible that macOS doesnt give the threads the appropriate priority, resulting in a loss of performance (and thus possible clicks). This is something I will fix in the near future; but so far I have not experienced any issue.
  • I also dont understand why 5.2.8 would provide a “strong improvement at this level” compared to 5.2.7. There is no “fundamental” changes between 5.2.7 or 5.2.8 in the spat audio engines.
  • Dont you experience similar dropouts in patchers not using spat ??
  • Can this be related to the use of Loopback ?? Does loopback behave nicely on the M1 ?


Hi Thibaut,

Thanks for getting back to me so quickly and for your insight.

Ok, looks like something about my personal configuration then. I modify it for every project but I will quickly detail the one I’m using now :

  • 32 Ableton audio tracks (sr 44100 - buffer 2048) are send to Loopback which routes them to a Max patch running the Spat (sr 44100 - signal vector 2048 - I/O vector 2048). In this patch, xyz or aed movement generators infos are send to the Spat which output audio in multi-channel format (quad or octo or else) to the RME.
  • Reaper multichannel outputs only to RME.
  • Ircam TS2 multichannel outputs only to RME.

Reading your answers, I now suspect Loopback to be one of the possible cause. Does Loopback take in charge all OS audio routes through ACE ? If yes, then that would explain why not only Max but sometimes all audio apps cut the sound. (FYI, I previously used the now discontinued Soundflower). I just asked Loopback’s support but your views on this are welcome.

spat5.oper @internals 16
spat5.spat~ @inputs 32 @internals 16 @outputs 4 @mc 1 @mode mono - /panning/type vbap2d, /parallel 1

Also these, though I currently don’t use OSC messages with Ableton
spat5.osc.udpreceive @port 4002
spat5.osc.udpsend @ip @port 4001
spat5.osc.speedlim @rate 5

And as you can see /parallel 1 : activated in my case. Could this explain some issues ? If : /parallel 0 will this lower processing power ?

Good to know. So, likely I along updated some other Software or OS which bought this improvement.


So far it works great… except if I discover it was the cause of the dropouts :wink:
I don’t use Blackhole because it is limited to 16 channels.

Maybe some things still need to be slightly improved for Apple Silicon. What is working for average use, may become unstable for power use. I’m aware I can sometimes be pushing the enveloppe in terms of CPU, but I always manage to find the limits since I’m performing live. In the case I describe, I reduced to 16 tracks to limit CPU load but the problem still occurs.

Oh and since I have the opportunity, thank you so much for developing such stellar software as Spat, the revered spatialisation tool in my palette since a long time :slight_smile:



I would suggest two directions :

  1. try to replace Loopback by something else.

Some alternatives (not all of them are available for mac/M1) :
JACK Audio Connection Kit (http://www.jackaudio.org), Soundflower (https://cycling74.com/soundflower), Loopback (Rogue Amoeba | Loopback: Cable-Free Audio Routing), BlackHole (Existential Audio · GitHub BlackHole), Dante Via (Dante Via, Pro AV Networking Software from Audinate | AV's Leading Technology), Voicemeeter (VB-Audio VoiceMeeter), ReaRoute (https://www.reaper.fm), Ground Control (https://www.gingeraudio.com), Virtual Audio Cable (VB-Audio Virtual Apps), etc.

  1. Try disabling the /parallel option in spat5.spat~. As explained somewhere in the documentation (and/or on this forum), this is a delicate option and I recommend NOT to use it as far as possible.
    The M1 is pretty powerful and [spat5.spat~ @inputs 32 @internals 16 @outputs 4] should be (almost) a piece of cake for such processor.


Soundflower is almost dead, no more supported by C74 but there’s a github project for Intel’s Macs on this page

Currently we mostly use BlackHole (macOS only) which seems to work great.
It can be extended to more than 16 channels, but you need to recompile it…

I did both :

  1. Use Blackhole
  2. /parallel 0
    No dropouts anymore on any running app. Moreover the CPU in the Max/Spat patch has lowered from 17% average to 3% average. Looks like the M1 doesn’t like the parallel option, I didn’t have the issue on Intel (maybe it was slowing down the system without me noticing, but there were no dropouts on Intel). It doesn’t look like Loopback was an additional cause though I’ll do further testing and let you know.

On another note, I was surprised to see CPU consumption much lower with a 256 buffer vs 2048 buffer. Not only in Max/Spat but also in Ableton. Does this mean that when using a virtual audio server a smaller buffer is preferable on both Out app and In app ? Does Spat prefer small buffers ? (FYI all my sources are in pretty constant movement)

Also does Max’s scheduler settings have a strong impact on Spat’s performances and are there recommendations ?


I just checked and : 2 channels, 16 channels and 64 channels version are available to download on Blackholes’s website : BlackHole: Route Audio Between Apps

Thanks for your feedback.
I’ll try to update the /parallel mode for M1 compatibility. Sorry for the inconvenience.

In general larger buffersize implies lower CPU consumption.
If you want all the details, have a look at Spat5-Benchmark.pdf.
(the benchmarks are made with Intel processor, but you get similar results with M1)

Spat internally operates in “Scheduler in Audio interrupt” mode, regardless of Max settings.
So, Max’s scheduler settings should not have a strong impact.
Nevertheless, recommendation is “overdrive ON + Scheduler in Audio interrupt ON”.