curious how you keep the lyric highlight in sync across players given this is browser audio, not a native client. each phone's audio pipeline has different buffering (bluetooth headphones alone can add 100-200ms of latency depending on the device), so if the highlighted line advances off local playback position rather than a shared server clock, two players on the same "beat" can end up seeing different words highlighted, which matters a lot for a game about lyrical timing. also on iOS safari specifically, an audio element started from one gesture and then paused/resumed later (someone switching tabs to grab a drink) can get stuck needing another user tap to resume playback, which for a fast round based party game would just look like the game silently broke for that person mid round.
the game doesn't play or stream any audio (though i think maybe a countdown timer or other fun sound effects would be nice)
players usually either a) play in real life on their phones or b) use something like Google Meet or Discord to sing their lyrics
that being said, the "buzz in" feature is sensitive to latency (but, in my experience, it usually takes players a few seconds to think of a song that fits the target word anyway)
does the reflash actually stall every live connection, or just the ones whose request lands during that window? if the whole board goes dark for the full ~25s while any request is queued behind it, you could probably hide most of that behind partial reconfiguration, reflashing only the region holding the model weights while the sequencer and I/O logic on the rest of the fabric stay live and keep draining the queue. that's obviously a much bigger lift than what you've built here, but it would turn a hard stop into something closer to a brief latency bump for whoever's unlucky enough to hit it, rather than a shared 25s wall for everyone behind them in line.
