This will cause FreeBSD to fail setting up the socket. It may also be true of some other operating systems, but these are the ones I have been able to test.
It works on Windows and Linux.
The `Config` object provided to `Call`s and `Driver`s allows setting a `DisposalThread`, but since it is unreachable from outside the crate, the only way to properly set it is using a `Songbird` instance, which may not be adequate for all use cases. This PR just makes `DisposalThread` reachable from the outside.
Fixes behaviour where a Driver which was asked to leave an active call would receive the disconnect event several times: once when we started the disconnect, and once again when Discord killed the WS client.
A little hacked together, but it is close enough to our primary format.
Will still require manual sorting of commits by function since we're not
doing conventional commits, but its lower friction for filling out
github usernames etc.
Previously, we were only skipping zero-packet frames when we needed to
resample because the source sampling rate was not set to 48kHz. This
check should have also been applied in the case that a packet did not
need a resampler to be built.
Fixes#224.
This PR fixes a case where a call which changes channel or gracefully
reconnects would have been stuck in the Idle state. SetConn events will
now allow a transition straight back to Live if any tracks are found
attached to a mixer.
* Add ytdl search
* fix fmt
* Remove compose, add tests, return AuxMetadata
* fix parsing of AuxMetadata and better test
* Fix playability of `YoutubeDl::new_search`
Refactors such that parsing of (ND)JSON is handled in only one location
now, which allows us to greatly simplify the actual `search` method. The
main change is that any `new_search` is now instantly playable.
---------
Co-authored-by: Kyle Simpson <kyleandrew.simpson@gmail.com>
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.
