< Back to IRCAM Forum

Multiple spat~ objects and CPU

Spat
#1

Hi everyone,
I’m creating a max patch that requires 10 individual binaural renders of a composition. I have therefore 10 instances of spat~/oper/viewer etc but the approach seems to be very CPU intensive. I have experiemented already with the binaural~ object and adding some individual components eg doppler, which seems less computationally expensive, however is missing alot of features inherent in spat~/oper and doesnt quite sound or “feel” the same. Largely the distance attenuation. Reading the forum I understand the reverb requires alot of CPU and perhaps this is the main culprit? My questions…

  1. Is there a way to manage CPU using multiple instances of spat~ etc?
  2. If using individual objects for each component is better, can you please help advise what objects/components are most important to replace spat~?
  3. Is there an alternative method?

Many thanks,
M

#2

Hi, I presume the 10 individual renders are needed for headtracking? My advice would be to make one mix, and do separate head tracking using [spat5.transform] or in the HOA domain [Spat5.hoa.rotate]. yes, you will need 10 binaural renders but only one [spat5.viewer]. All processing such as doppler, reverberation, attenuation and other effects are only computed once and rotated later. This saves CPU.

Doppler, and attenuation
Add the [spat5.source~] object to your input channels to create doppler, attenuation and air Freq

Reverb virtualisation:

Dedicate one spat5.spat or spat5.ircamverb~ to reverb, then spatialise the internals in the HOA domain. This way the entire ircamverb can become part of the HOA structure.

The main difference is, everything is computed once, except for the head tracking and binaural rendering.

Greetings, Marijn

#3

Have a look at this example:

I created a head tracked binaural situation for multiple headphones with low CPU usage.


----------begin_max5_patcher----------
1939.3oc6asraiaCEcs8WgfPWU33HR8tqlNn.ylY.JZWzEYFDPKS6vDYQUJp
7nES91KeHJK6HqnDK6joIFXhkEoz8xy8dHO7w7uiGYOidKtv15WrNyZzn+c7
nQpaIuwnpeOxdE51jTTgpZ1ojqwSmSPo1SzkdMhkgVg2rvyb+lo7EzjxhYT1
bLKglRYZi4L0E3FB8mriqbr9V0ySlqd0zYWdhqi4kliXBaxwrywYnYoJqCpJ
KqbEsjmh4JGFVcW8s32ki0Nfs8DK6EoTD2t1T4HdxEjrkmyvIbc0B8Bl5LwB
3FI+xyS82nFtmvZjLiwLtPA5Z77yQbNiLqjiWeUQExVAsRzKsDSWXts49Mag
ozrkcgvaT4UhfkrhtABLr0xIYxxOYWUn3BJiWat6P2zlULvXaufxLBufeWUL
QW92GOd8Wp+98wS5YB2JbQAZI1D443aUgF6SE9l0OAraIMo9lalJ.pyHy3Ej
+Q6f.CJzRFRcPV9D0XxuxZj82QJSTzTecxxDKHXWoLvmAjzSNH7PvAgQGcNn
OHVAn9fWabP36bvcvAgwunbvpTFnC3ElCBNHbvfiNGD5AlF27imqjQ5+ZiQB
dmQtKFY3KJir0DHni+KM+z4fHT83SPccm5I93GZv2vWkiXB7emftKBp+KJAs
sDnC33mqRlpxJVhHY22FGs0JzDt7d5bLucgYqJS4jjKPYY3zBhHwMUx5Vy7l
HygK5lAF6JQI20rM4zFCZfYh1NuxFIzxLdSV+QlP1F31JgLna5XXeXiOpw5M
uza+4kY3aDYOOfVVHBn9SufhlNijgJYnz6s9vpDKf0GTiHX41VJnq8Sqq7cj
l04BP35nRq70bPGstVX+5KW3jhWTG4MsQcbdk.tvCO356n3rv3f2ZfK3vCtv
3Hclq6aMv04vCt5AafQd+3hshAVmOCksrEDDLPqdf50+7jC4EnvTWkBZ+ftE
.A1aTooxGcR20D7MX1NxH0EZ8AhXzwaH7Kr9p8oEzRVB9TgiMSlXNwxbme9z
DZVAmIF9keZBgkTlhXVfuZad4ojLbshDiFobFt.mwQbBM67VqQyI7zd7xsq4
z7n43Ugf.UH..0+3UZNddJ5NoBw1TpB5bIScZE47MHGirTzySJGuJmpZlvZI
W1qny0YLyPEjDiQT+fKzMIy8EQKucROV2WSaWI+2bwaRD+Qr6ZDoHhHUBkIC
ThxZ1FVPSSo2rLkNqgG6zw3upQH70qtqVmSyYTyIhYQwYXwyUMY7FbY1JTFu
c2n07BCRlhyVxMuOoIElI4ph0su+tDkR328PfcNhi1NMJIkjWu+YMUdOxFMq
flJR8Dsak4ruTn.O8toHxhZQvhFBQ3PFl+NqwUjLc9DpbNgJuSiJTkpUF5H9
3FG30nrTJMuAJnbYQ2fBh84EBtMtdFCM77FOk4VUJtkWX8sCDKI3cVxtDRoF
r+DvaDdxbV4pOKx.6hozQc5EWA5DH3JQAtsvUbdVbEmAlqra8AtWQWk+.gAh
YYmiRt59VkjBfcKnpORReb4n5QpUqIPGhQcODxyYTYD59ZY4ZU5sfDQGgorC
U3.zMTQXiC+gdhO8FYiOdyW+MFxFdzlr9aMjM3nMScOv+G.VbVhPMEaajUNQ
z7RdQqi83ervXPU+tAQuDXrxVpoRu04oS4ux6uIvqmbdUa1brkZnbatPRmPG
lQy1Y0CeIqSqw1daHmdXHi2rWVRdJPdTKEODFJpGFBNHVJrGVJbHLTPeZRCh
k76gkBFhDud0j7GhlTeRwk6f3daodk34N.FpOTI4dlr2FpOI3vgn2gdkM3L.
FBzGKImhjXjr8zRvdXogHAGD02lz9ZI+9OpjYAWHyyojLd03f.Gn7PD.hhke
I2OSyupeBkXh5wUOntZb+cUe.rCWEbvc0v96ptNgc3pvCtqtIAq1vt62vEGK
tTe5Z8gcgqE7gxyuFyJpprxFBM0WpO9XQST+jjo+oR3oMCeMwTefZslrQLgh
VtPFZISuDO2VsHtpEujkURpx3DMOgMUmGhsTYtdisjq50eJl+SYw4eAmUpUe
KZUKPBg0aBEyVtfjlVeZ2Zp50HH2VW5Dy5307jwAi8.fn5yCWf5J4AiyW0S5
FOCv7Pd9dwNPYU8BfgdpCQmWDz02ciiSW0iAWaKGPr1BNwQNd5qD2BHrUyGC
ksTqQG13voXmyn4TV8BfN0Mtt9kb5RFZNAq2cqMk1OoJShIJs9XnTswY5YpX
dllYdaFLVQtceCB0NX6XpaXfWHPAIQdt.E33sEt7LgysB3CbPXHw5eSCtV.v
Gooys9cpbZkjtP9lai7YpMR1PvGHW4Kde9oZ+V1q5yp1sZKY6Zq4Aq2X1dFh
blF4O7svmAR67iYK8DvyLZ9NEebGQ6MOgFKPlAmACcDDcaXeRVeOZMLcHKva
K.z5OvKkG3D687sc4rY8m8E+N4q+juAIXeUQJQHU8uj5X6JN0n8pWQ7l+Yf7
E8xX+wzRb28XiRRvx8Fei+ydHC0RbOnVmZbUzencvOwv3rmrG5HcIeW4G4Uf
fHgL5A04TGfrOIFA9I6aRfxQk+5GCA9JbDzL+8o6f5YYo1hBoGVjWM7fZmLF
+8w+GSvx3QB
-----------end_max5_patcher-----------

All processing can be done in the Hoa Domain.

#4

Hi,

If possible, it’s preferable to use one single spat~ + oper/viewer, rather than multiple instances
(when using one instance with multiple sources, the sources can share the late reverb, therefore saving cpu)

When it comes to binaural, one crucial thing to look at is the HRTFs you are using.
For optimized CPU rendering, I recommend to use SOS filters, with 12 or 24 IIR sections (see spat5.sofa.loader)

With “only” 10 sources, things should run quite smoothly on most modern computers.

If you still face difficulties, please send a minimal working patch, so that it would be easier to pinpoint cpu intensive parts.

Best,
T.

#5

Hi
Thank you both for your responses.

Yes, each render is to facilitate headtracking, but I also require unique listening positions for each one (apologies, a detail I probably should have added). If I encode everything once to HOA and use a single viewer object, can I still decode with different listening positions? My other issue is that doppler etc would also be unique for each listener. Currently, for each I have the following.

spat5.viewer - spat5.abs2rel - spat5.oper - spat5.spat~

I could manage reverb separately as you suggest and will also look at the HRTFs. If, I did this and changed to using the spat5.source~/spat5.viewer/spat5.binaural~ per listener would this be acceptable? This avoids multiple spat~/oper objects but will having multiple viewer objects still be a problem? or should I still encode to HOA.

Many thanks,
M

#6

Using spat5.source~/spat5.viewer/spat5.binaural~ would be cheaper than using spat5.spat~.
But you would lose the reverb (which is really helpful for externalization and distance perception).

I recommend you first try with SOS HRTF, and “measure” your patch (you can do so with “Show CPU Usage” in Max/View menu).

Also, head-tracking can be intensive because it generally comes with high refresh rate. In most situations, it’s OK to “speedlim” the message to reduce the refresh rate, without noticeable difference (and that could save a lot of cpu).

HOA is probably not a viable option if you need different listening positions (each listener would require its own HOA decoder, and that is cpu expensive)

Cheers,
T.

#7

Hi, If you want different listener positions then indeed you need to do the processing for every source. That being said, you could share a reverb between the sources? Since the reverb is the most expensive part of the processing this could go a long way.

#8

Thank you both, thats given me some food for thought and options to try.

Best wishes,
M

#9

Hi
I’ve been trying out binaural~ and pan~ and they dont appear to support source orientation. Is this correct? Is there a way to use these objects that allow the source to be rotated? or a different object? I was using orientation modes lookat and fixed yaw for different sources perhaps this is the issue?

Thanks
M

#10

Hi,
Yes, this is correct.
Only spat5.spat~ supports source orientation/directivity, as this is achieved by adjusting the reverb level/filtering.

Best,
T.

1 Like