Assuming that the global audio offset is set perfectly, such that
any audio latency is fully accounted for, if a specific beatmap
still sounds out of sync, that would no longer be a latency issue.
Instead, it would indicate a misalignment between the beatmap's
track and time codes, the correction for which should be a
virtual-time offset, not a real-time offset.
First of all, this sort of cleanup isn't really the client's
responsibility, and secondly, at the point the client received this
request to disconnect, *none of its requests will be honored anymore*
(currently the only scenario of this if another client has connected
- the server-side concurrency filter will reject this request).
When disconnection is requested, the only valid thing to do with respect
to talking to the server is to stop doing it.
This will be moved server-side in a follow-up change, although I'm not
even strictly sure that's required - I'd like to think signalr would
know to clean up a disconnecting client from all groups they were in.