Feature Request: Configurable audio receive tick interval

[tt2468]

Is your feature request related to a problem? Please describe.
The current audio system processes new voice channel audio data on a hardcoded 500ms interval. For applications intending to use the resulting audio data as real-time as possible, this is a total blocker, as it results in a minimum of 500ms of audio latency.

Line in question:

DPP/src/dpp/discordvoiceclient.cpp

Line 167 in ffa2653

constexpr std::chrono::milliseconds iteration_interval(500);

Describe the solution you'd like
Having the ability to set this interval manually would be very helpful. I've tested down to 10ms intervals and dpp::on_voice_receive with no issues.

Describe alternatives you've considered
There's no way to even receive the raw opus payloads directly. Alternative for me is to go back to discordgo (what I was previously using) in order to get realtime access to the RTP payloads as they come in.

Additional context
None

[Jaskowicz1]

Hm, I like the sound of this! I guess it wouldn't be too hard to have something where the cluster could have something like bot.audio_interval(10). I'd like to see what others think of this and how we could implement it.

[Jaskowicz1]

My only concern with implementing this is what you stated in #1008, it caused the audio data to be "completely garbled". Of course, we'd need to figure how to fix that 😅

[tt2468]

My only concern with implementing this is what you stated in #1008, it caused the audio data to be "completely garbled". Of course, we'd need to figure how to fix that 😅

Well I'm not sure that it's the tick rate causing garbled audio... I think it's probably something else, considering the release binaries don't work either.

[Jaskowicz1]

Hmm, that is slightly alarming. If you can easily reproduce it, it may be worth filing a bug report for it.

…

On Wed, 22 Nov 2023 at 11:07, tt2468 ***@***.***> wrote: My only concern with implementing this is what you stated in #1008 <#1008>, it caused the audio data to be "completely garbled". Of course, we'd need to figure how to fix that 😅 Well I'm not sure that it's the tick rate causing garbled audio... I think it's probably something else, considering the release binaries don't work either. — Reply to this email directly, view it on GitHub <#1009 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALF2B6JPTKOD7OUD5ZOOLYDYFXMH7AVCNFSM6AAAAAA7RSY772VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRSGU3DENJUG4> . You are receiving this because you commented.Message ID: ***@***.***>

[Jaskowicz1]

I've released a PR for this :)

[Jaskowicz1]

The PR has been merged to implement this!