Interesting. So, when using AirPods Max (or Pro), and getting the spatial audio stream, does this mean Apple TV is not reencoding the MAT 2.0 signal to send to the headphones, and doing its "own" thing?
When driving Apple headsets, it bypasses the whole MAT thing, as it all locally routed inside the ATV. MAT is strictly an HDMI related thing.
Like, when using your Smyth A16 Atmos processor, it's relying (I assume) on the reencoded Atmos/MAT2.0 signal just like all our AVRs, etc., but how do the Apple headphones work? Is it some proprietary encoding used for their devices w/spatial?
When driving Apple headphones, the ATV routes the decoded DD+ Atmos stream to the Apple Spatial Audio renderer, which then performs binaural mapping along with headtracking (keeping the sonic 'image' centered to the screen as you turn your head) and sends that 2ch signal over Bluetooth to the headset(s).
This is much like the A16 in terms of audio rendering chain , the base DD+ with Atmos extensions is handed to a base renderer, which will then render into a 5.1.2 all the way to a 7.1.4 set of virtual speakers (the stream indicates how it was mixed). Once the virtual speakers have their 'signals', the Spatial Audio processing takes that and generates a binaural version, and integrates head tracking feedback as well.
The A16 adds two more levels, which are the speaker/room modeling performed during the initial render, and applying personalized HRTF and headphone EQ (optional) when generating the binaural signals. It is these two that elevate the A16 into a league of its own.
Plus, they would probably have to license Dolby for each headphone device, vs. only once for the iPhone, ATV, iPad, etc., so it would be added cost, not to mention the h/w required to do so in each headphone device. I would expect them to only want to decode it once; what value is there to reencode it in those situations? Which would then again point to an issue with their MAT2.0 encoding for non-Apple devices.
I kind of think Apple has a global license that gives them a lot of flexibility. That said, it is likely based on a per TVOS /iOS instance, with zero connection to accessories like headsets. The renderer requiring licensing rights is a part of those OSs.
The headsets have no 'spatial' HW nor code beyond the leveraging of the BT triangulation of earcups to BT base device used for head tracking inputs.
Much like the A16 can work with any headset, one just clips a wired head tracker to the headband of the cans. All the decoding/rendering/modeling happens in the box.
Finally, yes, the root issue does seem to be the MAT 2.0 stream handling when traversing an HDMI link.
Since that link runs at a huge number of different speeds (related to the video signal format), not surprised there are some corner cases where timing bugs have crept in.
I'll have more to say later, but simply running 4K HDR chroma at 4.2.0 vs 4.2.2 (a fast link required) seems to induce the issue more frequently.