< Back to IRCAM Forum

Any Tips for Making Spherical Speakers Sound Even Cooler with SPAT?

Hi, friends of the forum,

I’ve recently developed a strong interest in the beamforming of spherical speakers. Using open-source resources, I attempted a DIY project to create a 393-speaker array. With SPAT’s recent updates providing a more complete approach for IKO tuto, I’m particularly curious: if I use the 393-speaker array, can I employ spat5.iko.decoder~ as the final decoder and adjust the original output to 15?

Since my knowledge and experience with spherical speakers are still quite limited, I’d also like to ask about the differences between two approaches:

  1. Using hoa.encoder~ to transform a stereo or mono source into a 3rd-order HOA stream.
  2. Using beam control to encode into a 3rd-order HOA stream.
    What are the practical differences between these two methods?

I’d also like to share the patch I’m currently experimenting with!

393FIR.maxpat (146.8 KB)

Hello,

Wow, a 393-speaker, that’s an impressive DIY project ! Curious to know more about it !

As the name suggests, spat5.iko.decoder~ is designed for the IKO and cannot be used for other spherical arrays.
Also, decoding an HOA stream to a compact loudspeaker array requires a set of decoding filters. There’s (currently) no tools in the Spat package to calculate these filters.
(for the IKO, pre-calculated filters are included in the package, as wav files)
You’d have to compute these filters on your own. Then you can use Spat tools (such as spat5.hoa.slaconv~) to render (i.e. convolve) the decoding filters.

Also, be aware that decoding to IKO is extremely CPU-intensive; it involves 16 x 20 x 2048 filters
(where 16 == 3rd order HOA, 20 = number of speakers in IKO, and 2048 is the typical FIR filter length)
In the case of a 393-array, I doubt this can operate in real-time.

as the final decoder and adjust the original output to 15?

why 15 ??

the differences between two approaches

spat5.hoa.encoder~ encodes a mono signal to 3rd order HOA.
This is equivalent to creating a beampattern with “hypercardioid” shape.
See the attached patcher.

Hope this helps,
T.


----------begin_max5_patcher----------
2099.3oc6Zk0iihCD94t+UfPiz9R2IXtBYeZ1U6y6eftWEY.mDOMfivl9XFM
8u80GbXH.ARmLyNRqT24nJSJWe0oK3a2diYH4UD0z32Mdv3la91s2bijjfvM
ke+FyT3qQIPpbYlQjzTTFy7NEOF5UljNEkfhX3rcFOZt+sCn7HXdLlfiez7N
i2HE+VRhAIjAwYF4HZQBiZPwo3DXtAiXPO.YdK1SfKPYQjXT96UBHAmghHEY
Ro3VRju5n8bYsImKS0t212Zg0cFqjuB7juIHY7OkWSXQXXBRrXPIEbrbmSB+
x8.mJ4kUjhyRPLp9J4DIErJpVBhe+1aEub2DgsLzKb4bDp8L50C4FeZKvXoA
v23yzHHGQR4HfAnWDvdXDv0QpzNJf.Xo9liFDnzAF25ntBSyZV5XAXFXA3Lv
hFicLldHA91BTZHJNFEWI3CbWDtSFjgIYZZXfiTkr7Dus1U9ptItGPwWACtk
9E1MuMBpb2PHi055cHLGlhXn7MnLXoek0XvltJMLbZe4bsRHv3TDk13H0G7n
bVrCTwKRf0FbFtL1WYelD7ynELXXkXdFlmwM.s38.3eNgCDvGH8f.ReGWkqg
8I7fTPji0ZwapDKtm1+g++VtIfMfij2XNRZv1FQzOcS09ROEvbcyp9o5rB6d
sQNkTovmQwafLVNNrfgZ9DszXUZsDVjjBDYaE4J5s0vhzRLRrWf4BTJ9Oqgn
VKNgjs6XSrckIt0ZS49JZZaadjXQ9Ts.zVro6I4rdbkr5UPUVY6d3UjgYT1a
JS3ZEeoWd0ayzkWD7B2gNJvdYNLFCSVJpUfL9zDBuc77EuEXetg2V98Fdaew
BuGHG1ACLGTGQA8VuVofxLWNmuBtZN4uz2On7tABawInmQ4z1Qf2XBObPib6
XjT3WHxenfZGK91PQxulTN5Yb006USElyQEFGRJxUNwu56136J78yyJv0VFo
YobKIM.BmedI4H0EKrSUrav46WoJSnfYfJKpnbQcnqY3tDRzSnX8.MSxATFN
qaJmZ1wnsPdqfa1RxXT7WUI+D+38vea4NrWl0Av+QNOznVA1kiiIYhMgdPqj
bk33EEJ6WRWYjqHCdnmKl6uvgk1LqswTtRVPCg4BCUY175qjQHIsYUqKInsr
R1GvYYcPQF4vvLyw61Ox0FR3LSG62VxgxSeo3tg6Sv1Hx62dcvjjxnz1+7uB
yvoPFhgUl.aqZlpJZ6oQ4jjjVWlhyyMb.MV0mwQnWvwr8xqP2Yfub7gJmHyZ
qbLdGhxZSiA2QaSoN0rFohvxX3MLTJuSTVmEviNvTFuDwKzxEV4noC.MGfRO
lVOkWK5illuSp9XNnlIB4Mb9q6LVRx4Ay7ZyFK44FRM9aIQ9NiW9IaYDIgja
Dl.idpKUaN4BjFUJKm7DZfKQm4PWIaON5oLQ6k1ZLE6JXBOxhaOanxSHlXXo
qfsNRSfFi9RwqebFfms5aqzhVGOOe2b89N56j9pmMTMMsB5U01NGCtTdlSQo
cK67r50w03Pnn+vgz50Cp0VCq0ZbpN2ud7gTFYwnWuzPjZOLILx1e0HfjFBr
xZPD.LHBX8QQflRJxtu6OQgT4D76GZnjh7nJqbkKrQaEkmbjgypqv9PiNKV3
jLMydWrdh6hpsauvys5cjTdbCUI1QNqwrJELTyE79UBgIcxq2WEjyuE9QNZt
LZ8zM15Ha0xy8zM11J7ucysAW4CmOT264Hd+QwFKeAI5QgNh55pF.gqpWr0m
ae7AW6wPLzYx3aaeaOd2Jbv11yg+gl+tWvbcvpUkeAXCrb.xO4XsxNnhrEv1
2V+JGeDn5S3XpiHzobZXprk.W0HMBlMNu9mywAUCNTz5MukL16FeNZOj2xZB
UN6zznAlYpyIgLmSOUUK+Ed0sg35clyObFtm1yKkXuCj7hm4534za74xlRUF
.iOKNw9KX1diGMq6R8Qy4NN+RX21Uu6uw8TS4GFDW4Qf2kING3P4I9U2NTmZ
UUUdIXIDcl2u.vG89Er5mT0E3SsSSNhJ5T69bVkUt1S+RN0w3lAWb7zsELev
6Ti2l2JLOGkGP7pqrwA2fwGtsq+5l6ZVOWRu415LW6sjnBZnLKf7HipUZsvA
3rxluS5+SV8AzNtSbr3m88WY1i0tOsq8r6D2BOdaA08h1cHaSXv3hblByeIx
Y06.wKWzw.xIFatz2A3M5fyW2Lmk1rwRk59g3OmYqiRFah5VmZh5fO9D0mXb
l8ohyrksiOq3LGq+KEmYG7+wYWo3rfwuAUAmHPavELmHM3W+YGocwNmT4wjb
W42bLIKeewmz+etsWtV0PvJ8NfNiyA4ckaL.80XXz6iMl.P4V2o5XIcNbhdw
0YrYufOhK7VweezmAgxCkpdzLblPOZkM22ahseN8h9QOX5fNnV58letm57Wl
C6Tc2XpKOiQuHuaY3DL6M8cMY6VJhUmGucgN08gLNGt6n67jYTBN5I19bRwt
85zG5VUc7cpxpkTpFrXE0vccRSappooSYPycY5n.U+AhtLN+S6VWLP4ahehr
HDASiHYLtl79BNvyYX1i6hm0LRTn+.KIkc64bqr5cmrbos+nIJCrzmn7.SSV
73oUMM4i7ulrj.SPRh4aCZr.UlQv0Wxh4XpsnFOnOlnEOFGmFesVeI.XwSTw
OHY0AsttpkWKmhgjk+EQVASRuVcQhGlFF5cILWSRRW.AMEUJ3ZDnsZ5B9CIm
oDNeI7NDik4jBxWEX7wrXASTPeX+8IHGuKfBIKldZu8ePN6c2M8VRSUEuyCq
lPpcdH057.pc7Cm1vOXZcenzjmgenGFsa+9s+KvQI.dL
-----------end_max5_patcher-----------

Hi tcarpent,

Thank you for your detailed explanation! It gave me a clearer understanding of the IKO tutorial and how it’s specifically designed for compact loudspeaker arrays like the IKO. I’m curious about the decoding filters you mentioned—what tools are typically used to obtain accurate measurement data for spherical arrays like these?

The reason I attempted a DIY 393-speaker project is my fascination with how spherical speakers create what’s called a phantom source in a space. It’s that surreal experience where there’s no visible speaker, yet sound seems to originate from a specific direction. Through this project, I want to explore whether the decoding logic from the IKO tutorial can be applied to the 393-speaker array.

As for adjusting the output to 15, it’s because my 393-speaker array currently has only 15 drivers arranged in a spherical layout.

Perhaps my first step now is to use spat5.hoa.slaconv~ to render decoding filters for the 393 array.

Thanks again for your insights,
Xan

For the IKO, we typically use decoding filters provided by the vendor (Sonible).
I’m not aware of (open source) tools to generate decoding filters for your own array, but admittedly I havent searched recently.
As for measurement data for spherical arrays, this typically needs to be done in an anechoic chamber… so not exactly DIY !
Good luck with your project !
Best,
T.

I’m also interested in the subject.

As far as I understand, 393 and 170 developments in Graz were measured in a regular treated room.
In one of the papers I read that because of that limitation, they only took initial part of the recording to avoid indirect reflections of the room.

You can take a look at Gerriet Sharma’s presentation at IEM archive, page 25:

It shows a measurement setup for 170, not sure, but likely that’s the same as was used for 393s.

@tcarpent - mind sharing more info on computational intensity?
As I dug through the project documentation for 393’s (which are mixed-order arrays reaching 4th order on the equator and a lower order vertically), the decoding and convolutions are being done by Matthias Kronlachner’s set of plugins for Reaper. Did not explore it yet in detail, but I assumed it’s running real-time. For 393s it’s a set of 36 convolution files.

(original)

(2024 updated fork)
http://www.angelofarina.it/X-MCFX.htm

Hello,

Thanks for sharing the links and info.
Now I realized that I had misunderstood the original post: I figure that the 393 is the name of a speaker array using 3+9+3 = 15 channels ! While I thought the original poster was referring to an array with 393 channels. My bad. Very sorry for the confusion (I wasn’t aware of the 393-nickmane).

Nevertheless, decoding HOA for such compact loudspeaker array requires a set of N x M filters, where N = number of speakers/drivers and M = number of Ambisonic components.
In order to apply these filters, you need a (multichannel) convolution engine. You can use MCFX or spat5.conv~ (or spat5.hoa.slaconv~ which is just a wrapper around spat5.conv~) or any other. Although their implementations might be slightly different, they all do the same simple thing: a convolution operation.
A key question is to compute/design the said filters. As mentioned earlier, there is currently no tools in the Spat package to design these filters.

I hope this clarifies.
Best,
T.

1 Like

Could you give an explanation in layman terms of what these filters are doing specifically, and what is the process of creating them, even outside of spat suite?

From my understanding, there are 3 things happening, just not sure yet if simultaneously or as separate steps:

1/ Decoding (translating soundfield into discrete transducers)
2/ Crosstalk cancellation (i.e. adding opposite phase output to other transducers to counter down their passive resonance)
3/ Frequency response linearization

For the record, I’m not a sound engineer, but as many folks in the space I do get around with computers, basic maths, some programming and signal processing.

You know more than me on the topic ! So I cannot help you further.

You may find additional information there:

https://doi.org/10.1162/comj_a_00581

1 Like

Thanks for the links.
Yeah, the paper is on my list. It’s an extended version of what I read in 2019 Riedel’s paper on design of the 3-9-3. Also adding the books to my reading list.