You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
When subscribing to dpp::on_voice_receive_combined, the callback is only triggered once per audio tick (2 ticks per second, hardcoded). The audio data provided is generally only 960 stereo audio samples, or 1/25th of the expected amount.
dpp::on_voice_receive works as "expected", delivering 25x callbacks in sequence, per user, for every audio tick.
To Reproduce
Steps to reproduce the behavior:
Load a DPP bot into a voice channel with a music bot playing sound
Subscribe to combined audio data callbacks via dpp::on_voice_receive_combined
Receive only one callback of 960 (usually, sometimes many more) frames twice per second
Expected behavior
While not ideal behavior, one may expect that they should also get 25x callbacks of 960 samples of combined audio data per tick, instead of just one.
System Details:
OS: Ubuntu 22.04
Additional Context:
Patching the library to use a tick interval of 20ms instead of 500ms produces the correct number of callbacks per second (50), however, the resulting audio data is completely garbled.
The text was updated successfully, but these errors were encountered:
Describe the bug
When subscribing to
dpp::on_voice_receive_combined
, the callback is only triggered once per audio tick (2 ticks per second, hardcoded). The audio data provided is generally only 960 stereo audio samples, or 1/25th of the expected amount.dpp::on_voice_receive
works as "expected", delivering 25x callbacks in sequence, per user, for every audio tick.To Reproduce
Steps to reproduce the behavior:
dpp::on_voice_receive_combined
Expected behavior
While not ideal behavior, one may expect that they should also get 25x callbacks of 960 samples of combined audio data per tick, instead of just one.
System Details:
Additional Context:
Patching the library to use a tick interval of 20ms instead of 500ms produces the correct number of callbacks per second (50), however, the resulting audio data is completely garbled.
The text was updated successfully, but these errors were encountered: