Until 9/27/18, AudioReceiveHandler#handleCombinedAudio has been receiving all audio from the connected voice channel. After that date, the function has been writing blank data to the recording file, with 0 changes from me.
AudioReceiveHandler:
//user, warned, updated, channel, and file are defined. close() returns a File object.
@Override
public void handleCombinedAudio(CombinedAudio arg0) {
try {
left = limit - used;
if(updated && warned) {
channel.sendMessage(user.getAsMention() + " Recording termination canceled, you deleted a recording.").queue();
warned = false;
updated = false;
}
if(left < 1024*1024*10 && !warned) {
warned = true;
channel.sendMessage(user.getAsMention() + " Warning, you have less than 10 MB of space left (roughly a minute of recording time). The recording will stop if you do not free up some space.").queue();
}
if(left <= 0) {
closed = true;
channel.sendMessage(user.getAsMention() + " You ran out of space! The recording has been stopped (Recording ID: " + close().getName() + ").\n"
+ "Get more space by deleting some recordings or buying the Monthly Donor role. Details with the `donate` command.").queue();
return;
}
byte[] bytes = arg0.getAudioData(1.0);
if(!closed){
zipStream.write(bytes);
used += bytes.length;
}
} catch (IOException e) {
e.printStackTrace();
closed = true;
}
}
If I send this data back to Discord in my AudioSendHandler (which worked fine until the mentioned date), I can't hear anything.
AudioSendHandler:
//channel and BUFFSIZE are defined. BUFFSIZE = 3840
@Override
public byte[] provide20MsAudio() {
byte[] bytes = new byte[BUFFSIZE];
try {
int readBytes = stream.read(bytes, 0, BUFFSIZE);
if(readBytes < 1) {
closed = true;
close();
channel.sendMessage("Recording playback ended").queue();
return bytes;
}
//I'm reading from a FileInputStream from a zipped file. Occasionally, the unzipping process takes longer than 20ms. Better to block until we actually have data than sending what we have and facing the wrath of the opus decoder.
while(readBytes < BUFFSIZE){
readBytes += stream.read(bytes, readBytes, BUFFSIZE - readBytes);
}
}
catch (IOException e) {
//Oh well
}
catch(IndexOutOfBoundsException e){
//Oh well #2
}
return bytes;
}
This isn't just my issue. I suspect Discord made a breaking change.
I have asked the user to test something for me and they were able to receive audio properly pastebin. I myself am also unable to reproduce any issue with audio receive/send.
I made a video of my issue:
https://youtu.be/hxDeB56AJDQ
This video is completely useless to me, I can understand your issue...
Strange, your sample code works, but not mine 🤔
So, I started printing all the bytes in the array. They're all 0s. The bot has admin permissions, so that isn't a problem.
code + output
Don't comment on how I use JDA
@MinnDevelopment Based on additional conversation in #777 this seems that this wasn't actually fixed like specified in #653
Can you post your snippet that works?
Should I saturate the channel with silence as a temporary fix then?
I am able to receive audio without sending anything. The receive bug on discord's end was fixed according to this comment https://github.com/discordapp/discord-api-docs/issues/510#issuecomment-377355202
I'm able to receive audio while saturating the channel with silence (albeit in low quality), but not without. 🤷♀️
I was informed by @amishshah (hydrabolt, aka the discord.js maintainer) about similar issues related to audio receive functionality.
We now both agree that this has to be discord's fault. I will keep this issue open in order to track further development.
Is this issue still persistent? I'm unable to reproduce this behavior.
I believe this issue is a Discord one and still present, someone else had an issue with receiving audio recently and I told them to send a few seconds of silence first and it worked after that.
Is this issue still happening on build 450?
@MinnDevelopment looks like that fixed it. Thanks!
Most helpful comment
I was informed by @amishshah (hydrabolt, aka the discord.js maintainer) about similar issues related to audio receive functionality.
We now both agree that this has to be discord's fault. I will keep this issue open in order to track further development.