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.
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>
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.
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`.
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.
This PR makes use of `SampleBuffer::samples_mut` to remove a 7680B stack allocation in general, and memcopy when softclip is used. This appears to offer ~1.5% performance boost according to `cargo make bench`.
Adds a new field to Config, disposer, an Option<Sender<DisposalMessage>> responsible for dropping the DisposalMessage on a separate thread.
If this is not set, and the Config is passed into manager::Songbird, a thread is spawned for this purpose (which previously was spawned per driver).
If this is not set, and the Config is passed directly into Driver or Call, a thread is spawned locally, which is the current behavior as there is no where to store the Sender.
This disposer is then used in Driver as previously, to run possibly blocking destructors (which should only block the disposal thread). I cannot see this disposal thread getting overloaded, but if it is the DisposalMessages will simply be queued in the flume channel until it can be dropped.
Co-authored-by: Kyle Simpson <kyleandrew.simpson@gmail.com>
`youtube-dl` has a tendency to return mp4 files containing video and audio data vs `yt-dlp`. Naturally, the default stream in such cases will be the video data, so we fail to create a decoder.
This PR changes `LiveInput::promote` to first attempt to instantiate a decoder for the default track. If this fails to do so, then we reattempt this for all available tracks until one can be found. Previously, this method chose the default (or first available) track ID, and then failed if *that* track could not be decoded even if a compatible stream existed.
This was tested using `cargo make ready`, as well as manually verifying and adding a test case with a simple mp4 file.
`SsrcState` objects are created on a per-user basis when "receive" is enabled, but were previously never destroyed. This PR adds some shared dashmaps for the WS task to communicate SSRC-to-ID mappings to the UDP Rx task, as well as any disconnections. Additionally, decoder state is pruned a default 1 minute after a user last speaks.
This was tested using `cargo make ready` and via `examples/serenity/voice_receive/`.
Closes#133
Adds the "receive" feature, which is disabled by default. When this is disabled, the UDP receive task is not compiled and not run, and as an optimisation the UDP receive buffer size is set to 0. All related events are also removed.
This also removes the UDP Tx task, and moves packet and keepalive sends back into the mixer thread. This allows us to entirely remove channels and various allocations between the mixer and an async task created only for sending data (i.e., fewer memcopies).
If "receive" is enabled, UDP sends are now non-blocking due to technical constraints -- failure to send is non-fatal, but *will* drop affected packets. Given that blocking on a UDP send indicates that the OS cannot clear send buffers fast enough, this should alleviate OS load.
Closes#131.
