As from Chrome 71 WebAudioContext, it seems that the AudioContext starts as suspended on the page, until some requirements are filled.
One of them is that the user must interact with the page so that the AudioContext is released to work as intended.
My company maintains a website with various types of games and, since many of them can be from different game development tools, we use iFrames to load them.
My problem is that I can't find a way to enable/release the suspended audio from the iFrame, what would require to user to interact with the iFrame as well, not only the page itself.
Our games simply can't play their audio until the plays actually click inside the iFrame, and that's terrible, specially for games with music/sounds in their menu.
I couldn't find ANY ways of signing that those iFrames are fine to execute their audios, in my own webpage.
For anyone having this problem, as Kain has commented, allowing "autoplay" in the frame does work.
My real problem, that I came to notice way later, was that Chrome 71 had a bug when reloading the game in which the context would be blocked again, as if the user had come from another page.
If I clicked in the game in my website, waited the page to load, I'd have the audio context released. If, in the game page, I had the page reloaded, the context would be blocked as if I had come from another page.
Well, a bug. Maybe Chrome fixes this in future updates.