on_voice_receive, on_voice_receive_combined, and on_voice_user_talking never trigger events

[trackpadpro]

Git commit reference e52ed92

Describe the bug Windows x64 building using both release and debug in Visual Studio does not seem to allow for the bot to receive audio signals, even with admin privileges.

To Reproduce Steps to reproduce the behavior:

1. Make bot join a voice channel with a speaking user while having a on_voice_receive, on_voice_receive_combined, or on_voice_user_talking method

Expected behavior

1. Expect on_voice_receive_combined([](const dpp::voice_receive_t& event) or aforementioned alternative to trigger
2. With no logged warnings or errors, the bot does not trigger any of the events
3. The bot has been tested to send .pcm audio perfectly fine
4. x64 release and debug modes were both tried with the proper .dll files provided in latest release

System Details:

• OS: [Windows x64]
• Discord Client used for testing [desktop]

[Jaskowicz1]

Hi there! As far as I know, you need to send 0.1 second of blank audio first as Discord will not send you any audio unless you send something first.

[trackpadpro]

Does it have to be blank? I tried sending a non-blank .pcm using the bot and continued listening. I will play around more with that, but the example does not send audio first.

[Jaskowicz1]

Does it have to be blank? I tried sending a non-blank .pcm using the bot and continued listening. I will play around more with that, but the example does not send audio first.

It doesn't have to be blank, no :) Any audio works!

If it does work after sending something, I'll look to correct our documentation.

[trackpadpro]

What I tested:

1. Bot joins call

2. Changed my listener to the following:

   botPtr->on_voice_receive_combined([](const dpp::voice_receive_t& event){
   std::cout<<"\nsuccess\n";
   
   std::basic_string<uint8_t> audio = event.audio_data;
   
   std::cout<<audio.data()<<std::endl;
   }

3. Bot plays a ~3 second audio clip
4. Only while the bot is playing the audio did my terminal send a couple success messages. At any point after the audio was over, there was no more event trigger
5. There was never anything sent by audio.data()

[trackpadpro]

Using on_voice_receive instead did actually produce audio data to print to console, so the lack of data in my previous test may have been caused by the same issue as #1008. The audio receive event only occurs during the transmission event, however. Do I have to have a loop that sends an audio tick of 0.1s every second in order to continuously receive?

[Jaskowicz1]

@braindigitalis You know this area more than I do :)

[Jaskowicz1]

So, I'm under the belief that this is indeed a bug. We have a doc page that tells you how to record yourself and it doesn't state you should send audio first.

[Jaskowicz1]

From a bit of research, discord docs don't state anything about this, so I'm going to see if D++ is receiving any data and maybe not sending out the event.

[Jaskowicz1]

So, I'm seeing a bot get data without even sending data.

My testing program:

#include <dpp/dpp.h>

int main() {
    /* Setup the bot */
    dpp::cluster bot("token");

    bot.on_log(dpp::utility::cout_logger());

    /* The event is fired when someone issues your commands */
    bot.on_slashcommand([&bot](const dpp::slashcommand_t& event) {
        /* Check which command they ran */
        if (event.command.get_command_name() == "join") {
            /* Get the guild */
            dpp::guild* g = dpp::find_guild(event.command.guild_id);

            /* Attempt to connect to a voice channel, returns false if we fail to connect. */
            if (!g->connect_member_voice(event.command.get_issuing_user().id)) {
                event.reply("You don't seem to be in a voice channel!");
                return;
            }

            /* Tell the user we joined their channel. */
            event.reply("Joined your channel!");
        } else if (event.command.get_command_name() == "stop") {
            event.from->disconnect_voice(event.command.guild_id);

            event.reply("Left the voice channel.");
        }
    });

    bot.on_voice_receive([&bot](const dpp::voice_receive_t &event) {
        bot.log(dpp::ll_info, "on_voice_receive event fired! Data: " + std::to_string(*event.audio));
    });

    bot.on_ready([&bot](const dpp::ready_t & event) {
        if (dpp::run_once<struct register_bot_commands>()) {
            /* Create a new command. */
            dpp::slashcommand joincommand("join", "Joins your voice channel and records you.", bot.me.id);
            dpp::slashcommand stopcommand("stop", "Stops recording you.", bot.me.id);

            bot.global_bulk_command_create({ joincommand, stopcommand });
        }
    });

    /* Start bot */
    bot.start(dpp::st_wait);

    return 0;
}

This gives me the following:

[2024-04-03 15:05:40] INFO: on_voice_receive event fired! Data: 2
[2024-04-03 15:05:40] INFO: on_voice_receive event fired! Data: 254
[2024-04-03 15:05:40] INFO: on_voice_receive event fired! Data: 1
[2024-04-03 15:05:41] INFO: on_voice_receive event fired! Data: 253
[2024-04-03 15:05:41] INFO: on_voice_receive event fired! Data: 255
...

This was on Linux so I'll proceed to do more tests to find out.

[Jaskowicz1]

Yeah it's a windows thing it seems. I tested this with our latest VCPKG build and it doesn't fire there.

I'll see what I can do!

[Jaskowicz1]

As far as I can see, the issue lies within sslclient. It quite honestly looks like more of a headache to solve than an easy one, your best option is to either always send audio until this is fixed, or run your bot on Linux (again, until this is fixed).

[trackpadpro]

Alright, thanks for checking!

[github-actions[bot]]

This issue has had no activity and is being marked as stale. If you still wish to continue with this issue please comment to reopen it.