There is probably some followup cleanup which can be done, but keeping
the general structure intact might help if there are future changes on
available (non-E2EE) algorithms.
* Driver: Support `tokio-websockets`
* Fix bad feature flag
* Fix CI & examples features
* Use tungstenite in twilight example
* Error if none or both ws features are enabled
* Match `twilight-gateway` features
This PR adds support for the new AEAD cryptosystems advertised by Discord, AES256-GCM and XChaCha20Poly1305. These schemes will shortly become mandatory, and provider stronger integrity/authentication guarantees over the cleartext portions of any voice packet by correctly specifying additional authenticated data.
To provide smooth switchover, we've added basic negotiation over the `CryptoMode`. This ensures that any clients who are manually specifying one of the legacy modes will automatically migrate to `Aes256Gcm` when Discord cease to advertise their original preference.
Closes#246.
---------
Co-authored-by: Kyle Simpson <kyleandrew.simpson@gmail.com>
Bots joining calls with users seem to provoke large runs of packets
with identical timestamps -- the existing logic was intended to handle this catchup case in addition to the normal (+=960) at all
times.
However, we were checking that a packet was modulo greater-than
the next ts, rather than modulo less-than. Simple enough to fix.
Tokio-tungstenite have made some runtime-breaking changes to how
crypto setup is init'd -- i.e., users must do it themselves.
Reverting due to the huge (breaking) inconvenience this poses.
As of v0.9.1, `xsalsa20poly1305` has been deprecated. This is a mostly seamless replacement, as it appears to be the same crate authors / code / etc.
Co-authored-by: Kyle Simpson <kyleandrew.simpson@gmail.com>
This PR implements a custom scheduler for audio threads, which reduces thread use and (often) memory consumption.
To save threads and memory (e.g., packet buffer allocations), Songbird parks Mixer tasks which do not have any live Tracks.
These are now all co-located on a single async 'Idle' task.
This task is responsible for managing UDP keepalive messages for each task, maintaining event state, and executing any Mixer task messages.
Whenever any message arrives which adds a `Track`, the mixer task is moved to a live thread.
The Idle task inspects task counts and execution time on each thread, choosing the first live thread with room, and creating a new one if needed.
Each live thread is responsible for running as many live mixers as it can in a single tick every 20ms: this currently defaults to 16 mixers per thread, but is user-configurable.
A live thread also stores RTP packet blocks to be written into by each sub-task.
Each live thread has a conservative limit of 18ms that it will aim to stay under: if all work takes longer than this, it will offload the task with the highest mixing cost once per tick onto another (possibly new) live worker thread.
This patch changes around quite a few things.
The main entrypoint for twilight besides process will now be the
TwilightMap which concists of command senders for each shard.
This simplifies parts of the code as there is not any difference
between shards and clusters anymore.
Symphonia v0.5.2 has all the API changes and fixes we were depending on, which leaves next one step closer to publishable.
Tested using `cargo make ready`.
This PR Introduces a new `VoiceTick` event which collects and reorders all RTP packets to smooth over network instability, as well as to synchronise user audio streams. Raw packet events have been moved to `RtpPacket`, while `SpeakingUpdate`s have been removed as they can be easily computed using the `silent`/`speaking` audio maps included in each event.
Closes#146.
