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>
* chore(ci): Update rust setup and cache action
* chore(ci): Remove legacy-tokio from test matrix
This was removed as it doesn't seem to be used any more.
This PR changes the following things in the docs workflow:
- Move from the deprecated actions-rs action to the maintained alternative of dtolnay https://github.com/dtolnay/rust-toolchain
- Instead of manually defining the cache paths and the cache keys, I moved to an action that handles this for us: https://github.com/Swatinem/rust-cache
- As github decided at some point that the generated `GITHUB_TOKEN` secret will only have read-only permissions (for new repos), unless you tell them to be different, I added the `permissions` key to the job. This will not affect this repository, but will affect e.g. new forks (the workflow will not throw an permissions error any more - Read more here: https://github.blog/changelog/2023-02-02-github-actions-updating-the-default-github_token-permissions-to-read-only/ )
This change was done as the v2 version still used the node v12 runtime.
This runtime is deprecated by github. There are no other breaking
changes done by the action. With the update to v3 now node v16 is used
as runtime.
You can read more about the changes from v2 to v3 here:
https://github.com/actions/checkout/releases/tag/v3.0.0
A removed audio task could still have one or more driver messages left in its queue, leading to a crash when the id->mixer lookup failed. This removes an unwrap which is invalid under these assumptions and includes an extra cleanup measure for message forwarders under the same circumstances.
This was tested using `cargo make ready`.
`HttpRequest`s will now return an `AudioStreamError::Fail` on receipt of a non-2xx status code from a server. This has the advantage of making it clearer *why* a failure occurred rather than leaving users to piece the truth together from a Symphonia parsing error.
Closes#184.
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.
Moves all WS handling of unexpected payloads into the stream to prevent code duplication.
This also prevents non-{Hello,Resumed,Ready} messages from causing a handshake failure, as it seems Discord do not prevent such messages from appearing.
---------
Co-authored-by: Kyle Simpson <kyleandrew.simpson@gmail.com>
Receiving a new opcode while connecting to a voice channel was causing the connection to fail, while this was handled correctly elsewhere. Unfortunately, Discord added such a payload during every connection.
This PR moves the logging and conversion to no-op (and log) to catch both locations.
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.
If a link such as [this](https://www.youtube.com/watch?v=ygY2qObZv24&list=RDygY2qObZv24)
is passed to `YoutubeDl` without the option, it would cause a deadlock
in my bot.
There were many videos where it produced a `Silent` packet first instead
of mixed or passthrough. The URL I added was one that produced a
passthrough packet so I used that. Please let me know if this is wrong.
Windows CI runners appear to be very slow wrt. the time limits we've set for many of the tests, so fail for tests involving longer files. At the same time, MacOS tests aren't likely to add much value over Linux.
This commit disables *test* runners for these environments to remove a lot of commit/PR noise. Builds are still run on these platforms.
Fixes the possibility of a spinlock while reading bytes from an async->sync adapter. This case can be observed with long (e.g., 10 hours of silence) videos which seem to be served slower than we would like to parse their headers.
The fix moves most communication to blocking: `read` calls first parse all messages form the async context in a non-blocking way, then swap to blocking if no bytes are available.
Tested using `cargo make ready` and "examples/serenity/voice" against the URL https://www.youtube.com/watch?v=g4mHPeMGTJM.
Converts any `io::ErrorKind::NotFound` from `TokioCommand` into a more useful string for users, e.g., `"could not find executable 'yt-dlp' on path"`.
Tested using `cargo make ready`.
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`.
Replaces the annoying dual-return (i.e., created `Call` *and* `Result<x>`) with a single `Return<Call/ConnectionInfo>`. Users are now informed via that a `Call` is created -- thus, cleanup in event of connection failure is now their responsibility.
Tested using `cargo make ready`.
Closes#65.
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.
