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
Discord will send `GatewayEvent::Speaking` (opcode 5) messages
after the Hello+Ready exchange, but will happily interleave
them with crypto mode negotiation. We were previously not expecting
such messages and dropping them -- this hurts receive-based bots'
ability to map SSRCs to UserIds when joining a call with existing
users.
This PR feeds all unexpected messages into the WS task directly,
which will handle them once all tasks are fully started.
This PR addresses some issues which have cropped up on voice receive at scale:
* In unknown circumstances, we can be left with adjacent packets queued which have very different timestamps. The playout buffer would withhold its held packets, leading to the loss of many subsequent packets if the timestamp jump is larger than 64 frames. This seems to occur for some specific clients which join before a bot, suggesting the DAVE -> legacy switchover is involved.
* Some loss patterns can leave us unable to correctly track the next expected sequence number (i.e., large loss runs), leaving the playout buffer unable to accept any packets if the packet sequence differed by over 64 entries.
The fixes are fallbacks which treat sufficiently large desynchronisation, and allow the playout to get back into a consistent state in both cases. Large timestamp jumps on adjacent packets now update the next expected TS (noting that we only want to withhold a few playout delays at most ). Failure to insert 0.25s of packets (or attempting to add a new sequence number into an empty buffer) can now take precedence.
Closes#261.
* Receive: Config of decode sample rate/channels
This PR allows for dynamic configuration of the output sample rate and
channel count of received Opus audio. Users who rely on supported
formats should no longer need to manually resample & downmix audio
decoded from SSRCs in a call.
Opus exposes tuples of (Mono, Stereo) x (8, 12, 16, 24, 48)kHz.
Changing this at runtime (mid-call) may cause some audio glitches, as
decoder state must be reconstructed from scratch for all affected SSRCs.
* Fix doc typo, consistent naming with MixMode.
This changes HlsRequest to return true in
Compose::should_create_async.
This would otherwise cause it to be spawned on a thread without a
executor causing it to panic.
This would only cause issues if used directly since we otherwise use
Compose::create in a context where we have access to the executor.
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>
A few tests are routinely failing on CI because they explicitly
hit YouTube URLs, even if the content in question is CC-licensed.
This PR simply adds the `#[ignore]` attribute, and adds the
`--include-ignored` flag to `cargo make test` so that correct WebM
parsing behaviour can be locally verified.
We could go a bit further and conditionally ignore the tests based
on CI-specific ENV vars, but that's probably overkill given the
scope of the issue.
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.
Ringbuf 0.4.2 onwards adds in a new storage type for `SharedRb`.
Unfortunately, this is handled in such a way that we fail to
compile because an explicit type parameter is required to
disambiguate the method in question.
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.
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>
