discord-jda / JDA

Java wrapper for the popular chat & VOIP service: Discord https://discord.com
Apache License 2.0
4.35k stars 734 forks source link

Audio is sometimes sending at double speed #357

Closed freyacodes closed 7 years ago

freyacodes commented 7 years ago

I have been getting reports that sometimes audio is sped up significantly. This seems to be an issue with how JDA sends audio. My guess is that JDA is requesting two frames every 20ms as opposed to just one. This doesn't seem to be lag, as I was experiencing this on a bot with low network and CPU load.

Setting a new sending handler seems to temporarily fix this. It could possibly also be a lavaplayer issue as I am instantiating the player with the sending handler, but I doubt that.

Leaving a VoiceChannel or changing the server region has no effect on this.

@kodehawa is also experiencing this.

rainestormee commented 7 years ago

I am also having this issue with the latest builds of JDA/Lavaplayer at the moment. Users are reporting a 3x speed up in audio.

iBlitzkriegi commented 7 years ago

I too have this issue.

DV8FromTheWorld commented 7 years ago

Do any of you use NAS. What build did you start seeing this occur?

freyacodes commented 7 years ago

I'm using NAS on build 193

On 16 May 2017 at 18:15, Austin Keener notifications@github.com wrote:

Do any of you use NAS. What build did you start seeing this occur?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/DV8FromTheWorld/JDA/issues/357#issuecomment-301834214, or mute the thread https://github.com/notifications/unsubscribe-auth/ACdoWU-4HTYLQWnffSt1BE-OzRaLAP25ks5r6cuxgaJpZM4NccVk .

Kodehawa commented 7 years ago

Started on build 193 too. Removed NAS with no change in behaviour.

MinnDevelopment commented 7 years ago

Some people reported to me that this is immediately after reconnecting with the close code 4003 which was fixed in build 194/195. Would you be able to reproduce this behaviour on the latest build 200?

freyacodes commented 7 years ago

I heard from one of my users that audio was sped up, though this time the bot is under heavy load. Running on 3.0.0_200.

Kodehawa commented 7 years ago

just received an audio sped up report on 3.1.0_204 without JDA-NAS

Fabricio20 commented 7 years ago

Just got a report of speeding up on JDA 3.1.0_204 with NAS.

MinnDevelopment commented 7 years ago

All this doesn't contribute to finding the issue. I need more information on how the speed up is caused, how it behaves, how you fix it, how global the issues is (does it affect more than one guild?), etc.

Kodehawa commented 7 years ago

Affects only one guild. The fix is to unregister the AudioSendHandler of the guild for everyone (and for all devs I've talked to) having this issue. You can sometimes replicate it by spamming open/close audio connection, but the issue is rather random. It behaves in intervals, at first it's 2x, and goes up and up the more time you leave it there.

Kodehawa commented 7 years ago

dump.txt

Attaching thread dump after... I got it in my own guild

DV8FromTheWorld commented 7 years ago

Unregistering the AudioSendHandler would kill the AudioSendSystem, thus killing the one that we want to have (for normal sending) and killing any others that are ghosting. This, along with some information in the Discord channel basically confirm that there are ghost AudioConnections running that are siphoning audio information out of the AudioSendHandler.

Additionally, based on the fact that it has been stated that the problem can be generated due to quick succession of Open/Close or due to disconnect/reconnect, it leads me to believe that something in the recent change to make the connection system asynchronous has caused a racecondition. That, or AudioConnections are not being properly destroyed during those conditions.

Will continue my investigation. Thank you everyone for your continued investigation.

Fabricio20 commented 7 years ago

Got another report, guild Id is 270310054790430721 dump.txt

DV8FromTheWorld commented 7 years ago

Please give the bug/audio-speedup branch a try. I believe the change in logic there will fix the issue.

freyacodes commented 7 years ago

I received a couple complaints that suggests that the fix is not working since I updated to the speedup branch. image image

DV8FromTheWorld commented 7 years ago

@Frederikam run on 3.1.1 for now. If you get additional reports, let me know.

Fabricio20 commented 7 years ago

Currently running on 3.1.1_210 and still got reports of double speed audio.

image image

Kodehawa commented 7 years ago

Got 2 reports of it happening here too. Seems to happen less, but still happens, sadly.

MinnDevelopment commented 7 years ago

Since you have gotten new reports I'll reopen this issue for further investigation.

Kodehawa commented 7 years ago

https://mantaro.ratelimited.today/35aab1.jpg Yeah, I get up to 5 reports/day again. Ohh well.

ducc commented 7 years ago

If it's worth anything I never experience this.

bddvlpr commented 7 years ago

"Register your AudioSendHandler: audioManager.setSendingHandler(myAudioSendHandler) You may only use one AudioSendHandler per Guild and not use the same instance on another Guild! Doing that will result in speedup due to multiple send threads pulling from the same instance!" Idk if this helps

src --> https://github.com/DV8FromTheWorld/JDA/wiki/4)-Making-a-Music-Bot

DV8FromTheWorld commented 7 years ago

While that is true, that is not what is causing the problem here. At least it shouldn't be. Might not hurt to add an iterative check to make sure that it isn't registered somewhere else.

Kodehawa commented 7 years ago

@ducc You're using _176 tho 🤔

Ritchie454 commented 7 years ago

Devs this is still a bug, we need a fix PLES

MinnDevelopment commented 7 years ago

@Ritchie454 if you can tell us exactly how to fix it then please do, otherwise this does not contribute to fixing it. We are looking into this bug as you can see the issue is still open for that exact reason.

Kodehawa commented 7 years ago

The issue seems to lay on LP example (https://github.com/sedmelluq/lavaplayer/blob/master/demo-jda/src/main/java/com/sedmelluq/discord/lavaplayer/demo/jda/GuildMusicManager.java#L32) on how SendHandlers are created. Every bot that doesn't use that, doesn't get the speedup.

Changing that to a variable and updating it in the constructor seems to fix it or at least the SpeedingTicketFactory isn't spilling a lot of things at me.

I found it because on a speedup guild I did .getSendHandler and music got faster, then faster, then faster every single time I ran it.

Basically seems that what @StijnSimons says it's kinda true, it creates multiple in very niche occations using what's in the example.

Weirdly, with the same code this didn't happen prior to 193.

(Seems to happen even if you don't set it, just getting the method in a sped up guild was enough to give more speedup somehow)

Kodehawa commented 7 years ago

Nope. Still happens so I take back what I said.

Tho, it was interesting to see that making it speedup more everytime it was called.

MinnDevelopment commented 7 years ago

Could you guys try out patch-speedup using jitpack and report back?

DV8FromTheWorld commented 7 years ago

https://jitpack.io/#DV8FromTheWorld/JDA/patch-speed-v3.1.0-g4d4a382-15 I believe

MinnDevelopment commented 7 years ago

This should be fixed as of e5f023d

ducc commented 7 years ago

😅 💦 😅 💦 thanks 😅 💦 for 😅 💦 the 😅 💦 fix 😅 💦 boys!!! 😅 💦 😅 💦

Kodehawa commented 7 years ago

🎉

exellian commented 4 years ago

Still happens with version 1.3.7

DV8FromTheWorld commented 4 years ago

I'm sorry, what? This issue is from 3 years ago and JDA is on major version 4 at this point.

Are you saying you're still using JDA Major version 1?

Chew commented 4 years ago

Might be referring to LavaPlayer 1.3.7 (though it's on 1.3.49) is my only guess.