* Resolve issue with copied v1 struct
* Speaking event patches, support Client Connect/Disconnect events
* Remove extra debug in heart.go
* Initial voice packet reading
* Resolve unallocated slices, use a static slice/array for decryption, split version/type
* Use separate slice for recvOpus, check return of secretbox.Open, and use constant for header size
* Update missing reference to packetHeaderSize
* Resolve decryption issues, add ReadPacket to session
* Update documentation for recvBuf/recvOpus
* Update comment for recvPacket's array
This comimt adds a method into the UDP connection to control the
internal frequency ticker which controls the speed of playback. For more
information, refer to (*voice/udp.Connection).ResetFrequency().
StopSpeaking is removed because it no longer works with variable
parameters. The functionality of that method was also arguably useless,
as it only sends silent frames.
This commit adds multiple thread safe guards to do better the
concurrency promises. However, it also omits completely those guarantees
in certain places that don't make sense to call concurrently. This is
mostly documented.
This commit also adds a small piece of code to concurrently run things
with the race detector.
This commit omits thread safe guarantees in the UDP voice connection.
This is done because the UDP connection should not be shared across
threads, so those guarantees are now omitted for performance.
Session will still guard a UDP connection around a read mutex, because
Session itself has thread safe guarantees. This may change in the
future.
This commit fixes race conditions in both package voice, package
voicegateway and package gateway.
Originally, several race conditions exist when both the user's and the
pacemaker's goroutines both want to do several things to the websocket
connection. For example, the user's goroutine could be writing, and the
pacemaker's goroutine could trigger a reconnection. This is racey.
This issue is partially fixed by removing the pacer loop from package
heart and combining the ticker into the event (pacemaker) loop itself.
Technically, a race condition could still be triggered with care, but
the API itself never guaranteed any of those. As events are handled
using an internal loop into a channel, a race condition will not be
triggered just by handling events and writing to the websocket.