[REQUEST] add 4th order (or more) ambisonics
TheBestKmanEver opened this issue · 5 comments
for both HRTF and speaker layout
Higher orders is something that could be nice to support. For fourth order, the main issue is being able to take advantage of it; speaker layouts aren't typically dense enough to utilize higher orders, for instance a 7.1 surround sound setup doesn't really benefit from even third order since there's not enough speakers to resolve the spatial detail, without succumbing to problems ambisonic panning attempts to address (sounds sticking to speakers, or having holes in between, as it pans around). HRTF may have more room to benefit with denser datasets, though less dense datasets will have the same problem if the virtual speakers don't line up well with the responses' locations. If there are ways to improve the output with higher orders despite having a low density of speakers, I'm not aware of it. The main use would be with outputting it directly to some external processor that can make use of the spatial resolution, and/or saving for future-proofing.
Orders above 4th may need more work to support, as there are places in the library that expect to use bits of an integer in relation to ambisonic channels. 32-bit integers allow up to 32 channels, which is fine for 4th order at 25 channels, while 5th order is 36, 6th order is 49, and 7th order is 64, which would need 64-bit integers. The panning coefficients for the higher order channels will also be needed, which I currently only have up to 4th order noted down. The NFC coefficients will also need expanding for higher orders, presuming the NFC filters will even still work at such higher orders.
Doesn't hrtf-mode=full (default) already use all available HRTF positions independently from ambisonics order?
Or is this for an edge case that explicitly requires an external ambisonics spatializer instead of letting OpenAL Soft spatialize each source individually for better positional accuracy (as much as the HRTF density allows)?
Speaking of, how dense would the HRTF need to be to reproduce the equivalent of 35th Order Ambisonics? 🤔
IIRC that's 1296 channels, and SADIE II has ~3-9K positions, so I wonder how many would be enough since we need more (virtual) speakers than ambisonics channels and a high enough order for HRTF to match the real position:
3OA:
35OA:
Doesn't
hrtf-mode=full(default) already use all available HRTF positions independently from ambisonics order?
Yes, but full HRTF mode adds more CPU cost per source than using the ambi* modes, so people may want to use them. I also regularly think about changing the default to one of the ambi modes to reduce the CPU overhead when a number of sources are playing, and because effects process an ambisonic mix, which would also make the final mix more consistent.
Speaking of, how dense would the HRTF need to be to reproduce the equivalent of 35th Order Ambisonics? 🤔
IIRC that's 1296 channels, and SADIE II has ~3-9K positions, so I wonder how many would be enough since #999 (comment) and a high enough order for HRTF to match the real position:
Full 3D 35th order would need more than 1296 channels (it's not clear exactly how many, but more is better as long as it's not overboard). But just as importantly, they have to be placed in an appropriate layout, which would need a decent amount of precision. Concentric rings at fixed elevation and azimuth steps, like mhr files use, aren't great for that without the step size being very low (only a few degrees), otherwise multiple channels would end up at the same location.
For even ITU 5.1 , 4th/5th order may be beneficial since the angle between L & C is 30deg, but the resolution of 3oa is only 45deg. 5oa has resolution of 30deg.
Yes, but full HRTF mode adds more CPU cost per source than using the
ambi*modes
Are we talking like significant usage even on modern desktop CPUs or just low-end/mobile devices? 🤔
Full 3D 35th order would need more than 1296 channels (it's not clear exactly how many, but more is better as long as it's not overboard). But just as importantly, they have to be placed in an appropriate layout, which would need a decent amount of precision. Concentric rings at fixed elevation and azimuth steps, like mhr files use, aren't great for that without the step size being very low (only a few degrees), otherwise multiple channels would end up at the same location.
Dang, I just noticed that SADIE uses just ~1/3 IRs of the total ~3K, because of incompatible layout, I presume 😔
At least EAC only loses about a hundred
On a side note, could OpenAL Soft add Higher-Order Ambisonics decoding to apps like sView (limited to 1OA) or should every app add HOA decoding on its own like Virtual Home Theater which supports up to 3OA?