This change increases the version of DiscoRTP, which fixes upstream issues in libpnet and allows additional RTCP types to be added over time without breaking semver. This is a breaking change for users explicitly matching on RTCP packet types, as DiscoRTP is exposed here.
This has been tested using `cargo make ready`.
Joining a channel returns a future which fires on receipt of two messages from discord (by locally storing a channel). However, joining this same channel again after a success returns only *one* such message, causing the command to hang until another join fires or the channel is left. This alters internal behaviour to correctly cancel an in-progress connection attempt, or return success with known data if such a connection is present.
This introduces a breaking change on `Call::update_state` to include the target `ChannelId`. The reason for this is that although the `ChannelId` of a target channel was being stored, server admins may move or kick a bot from its voice channel. This changes the true channel, and may accidentally trigger a "double join" elsewhere.
This fix was tested by using an example to have a bot join its channel twice, to do so in a channel it had been moved to, and to move from a channel it had been moved to.
Debugging work put forth by JellyWx and jtscuba suggests that this WS thread receive is ending up in a permanent failure loop. This adapts the timeout-less receive such that receive failures are properly propagated.
This was tested using `cargo make ready` and using the `voice_storage` example (although I cannot repro the locking behaviour myself).
Comments in #69 suggest this is fixed -- closes#69.
The upstream crate `spinning_top` used newer elements of rustc's std in a patch release, unknowingly bumping its MSRV to 1.49.0. This patch reverts to the older, compatible, version.
This has been tested by manually building `examples/serenity/voice` using rustc v1.48.0.
Closes#62.
Leaving (rather than removing) a call would cause the driver to crash as it would try to use a non-existent connection immediately after it had been invalidated.
This has been tested using a modified `examples/serenity/voice_storage`, felyne, and via `cargo make ready`.
Updates to the latest async-tungstenite version. This was tested by `cargo make ready` and by testing driver/gateway function via `examples/serenity/voice_storage`.
This is a simple addition to allow current connection state to be retrieved *after* establishment, even when using the voice driver.
This has been tested using `cargo make ready`, as it is fairly simple functionality.
This change reduces many log levels to debug, particularly where errors are likely to be triggered by undocumented Discord messages or by threads exiting in an unpredictable way. This also reduces the task entry/exit messages to `trace`.
This PR has been tested via `cargo make ready`, and by manually inspecting logs at `debug` and `info` levels running `examples/serenity/voice`.
* Add Makefile for common contributor tasks
Narrows down a few commands to automatically format when building, and neatly expose testing/benching.
Empty files added to describe contributor guidelines, overall architecture.
* First draft of contributor guidelines
* Simple architecture diagrams
* Add PNG variants of architecture diagrams
Swapping to these because not having Fira Sans installed on a viewing machine leads to terrible kerning.
* Architecture description.
* MD cross-refs.
This change prevents mixer threads from waking every 20ms without an active voice connection. This was leading to unacceptably high CPU usage in cases where users needed to preserve this state between many active connections. Additionally, this modifies the documentation of `Songbird::leave` to emphasise why users would prefer to `remove` their calls.
This was tested by examining the CPU usage in task manager before and after the change was made, using a control of 10k manually created `Driver` instances. After creation is finished, the Drivers no longer saturate a 6-core laptop Intel i7 (while they very much did so before).
Closes#42.
Changes a stored `Arc` pointer to the call (used to queue up further tracks in response to events) into a `Weak`, as the event handler's strong pointer would keep the Call and Driver objects alive. This would have caused an unintentional resource leak of threads/tasks. This was found by some internal profiling in search of #42.
Knowing your own SSRC is useful for handling RTCP packets, which may detail information about *ourselves* rather than another host. In theory, at least: this confirms that Discord just sends ReceiverReports containing your own packet stats.
This would have been better to fit into Driver(Re)Connect, but that would be a breaking change: when this change is made, `SsrcKnown` shall be deprecated.
Adds support to the library for tokio 0.2 backward-compatibility. This should hopefully benefit, and prevent lavalink-rs from being blocked on this feature.
These can be reached using, e.g., `gateway-tokio-02`, `driver-tokio-02`, `serenity-rustls-tokio-02`, and `serenity-native-tokio-02` features.
Naturally, this requires some jiggering about with features and the underlying CI, which has been taken care of. Twilight can't be handled in this way, as their last tokio 0.2 version uses the deprecated Discord Gateway v6.
This should make dropping `ChildContainer`s and their parent `Input`s safer in async contexts.
It seems like SIGINT is insufficient to make wait terminate, but SIGKILL suffices. This introduced a new problem, namely that we have to remember and wait on *every* pid we create. This should, hopefully, put the issue of zombie processes to bed for good.
Linux/Unix requires that processes be waited, which is unfortunate as Windows lets us abandon them to the murderous whims of the OS. This PR adds Unix-specific behaviour to send a SIGINT before waiting on the process, and adds an additional thread per call for asset disposal on all platforms.
Closes#38.
---
* Close processes by SIGINT and wait on Unix
This seems to remedy the Linux-specific zombie processes. Addition of
nix as a dependency *should* be fine on Windows, since I believe it
compiles to an empty crate.
* Dispose of Tracks on auxiliary thread
This adds a mechanism for the mixer threads to perform potentially expensive deallocation/cleanup outside of the main loop, preventing deadline misses etc. This should make misbehaving `wait`s a bit more friendly.
Moves to the faster dashmap in the Songbird management struct, as the final v4 brought back the `entry` API that I was needing to use it safely.
Also handles some new clippy lints.
These should allow bots to hook up events to a variety of important connection events as required. This was primarily motivated by the user who raised dcb6ad9.
Although I really would have liked to squeeze in (finite) reconnection attempts with exponential backoff, so that automated repeat attempts could be neatly handled, `Config` was accidentally *not* made non-exhaustive. Adding this and its needed configuration would then be a breaking change. This should warn users about an accidentally dead connection, until the next version can be put forth.
Closes#26.
This will also prevent a full reconnect failure from endlessly spamming attempts and error logs. I'll follow this up by looking into decent reconnection strategies, although sadly these won't be configurable until the next semver break due to an oversight on my part.
Migrates to the new version of tokio, requiring channel and sleep changes in a few locations. Additionally points to the in-tree v0.3 version of twilight.
Adds a shared TypeMap per TrackHandle. This should greatly simplify the user experience for attaching additional per-track state which the driver does not care for.
This change is made with queue users in mind. Since sources
of this kind *know* how to (re)create themselves, they can
avoid being created at all until needed.
This also adds machinery to preload tracks *before* they are
needed, for gapless playback on queues and so on. Queues
make use of the event system to do this.
Potential deadlock (identified by a user) has now been warned about. The way the example is structured prevents this from occurring, but it's worth making this more explicit due to the more free-form nature of twilight.
The design of serenity's event handling and framework should prevent this issue from cropping up when using it as a gateway backend.
* Driver Benchmarks
Benchmarks driver use cases for single packet send,
multiple packet send, float vs opus, and the cost of
head-of-queue track removal.
Mix costs for large packet counts are also included.
This is a prelude to the optimisations discussed in
#21.
* Typo in benchmark
* Place Opus packet directly into packet buffer
Cleans up some other logic surrounding this, too. Gets a 16.9% perf improvement on opus packet passthrough (sub 5us here).
* Better track removal
In theory this should be faster, but it aint. Keeping in case
reducing struct sizes down the line magically makes this
faster.
* Reduce size of Input, TrackHandle
Metadata is now boxed away. Similarly, TrackHandles are neatly Arc'd to reduce their size to pointer length (and mitigate the impact of copies if we add in more fields).
