To provide more context, the last change to our experimental audio driver code was made on Feb 8 2022. So any changes in behavior you may have noticed since then, are entirely because of tvOS and homepodOS updates and bugs. As others here have said, sometimes rebooting the home pod will fix issues for a while.
When we started working on this last year, we isolated several issues in the audio APIs and reported them to apple. We provided diagnostics and sample projects that reproduce the issue. The bugs were confirmed by apple but we didn't hear anything back. Then we escalated and opened a technical support ticket. We spent months going back and forth with an engineer about workarounds, each of which was implemented into the experimental driver and released to everyone here for testing and refinement. We attended 1:1 meetings with audio api engineers at WWDC over the last two years to follow up on what's going on with this issue. So when I say our hands are tied, I mean that we have exhausted all technical possibilities and things are out of our control. We are engineers, not magicians.
Anyway, Apple's ears must be ringing because I heard some updates on one of the bug reports I have open today. The issue is still not fixed, but they suggested a workaround that improves things with tvOS 16.1. You can try it out in the latest TestFlight build.
In my testing it does help with the insane 4-5s delay their API usually shows, reducing it to around 1s. The effect is more dramatic on recordings where the homepod can buffer ahead more quickly.
(To be clear, the issue is literally that we call play()
on their airplay audio api but it refuses to play and just randomly hangs for 1s-5s.)