Implement playing audio through discord voice connections.

[BrandtHill]

Implement voice 👍

closes #84

[queer]

Isn't latest stable 1.10?

[BrandtHill]

I just changed it to what mix.exs is set to

[BrandtHill]

Going to change the wording as well as some other fixes, stay tuned, very spicy commits inbound

[Kraigie]

Just wanted to say thanks first and foremost! This looks like it took a lot of work. I'll have some time this weekend to go over the code and check it out!

[BrandtHill]

1337 lines added (nice). If you average one line a minute, it should only take a little over 22 hours.

[Kraigie]

This is sick! I tested it out locally and things worked flawlessly. My only complaint would be with the errors related to ffmpeg or youtube-dl not being available.

Right now if you don't have those configured properly you get what I believe is probably a porcelain error saying the command isn't available.

** (ArgumentError) argument error
    :erlang.apply({:error, "Command not found: ffmpeg"}, :out, [])

** (MatchError) no match of right hand side value: {:error, "Command not found: youtube-dl"}

I think we should probably improve these a bit, or even prevent them from happening in the first place. We can either be proactive or reactive and I'm not sure what's the best approach.

Proactive

My first idea is that we could check somewhere that the user has the two programs in their path, or at the path they specify in the config. However, I'm not sure where it would be best to do this.

We could optionally have the user set an option in the config that specifies that they want to use voice and then just check that the programs exist on startup if they intend to use voice.

Or we could also just do it every time the voice supervisor starts up. This might be problematic because I don't think we'd want to warn when this happens because they might not be using voice, but users may miss an info. Maybe that's OK though.

I can't think of a way to check before the function calls themselves that doesn't involve spinning up porcelain every time so this might be out of the picture.

Reactive

Alternatively, and this is probably the better idea, we could just check for those errors and throw an exception. Things aren't going to continue anyways without those tools so blowing it up seems reasonable. This doesn't change much from how it acts now, but it tells the user explicitly what is wrong!

[BrandtHill]

I've done some of both: I've added a suppressible warning message upon startup if the configured executable(s) weren't found in the system path, and running either ffmpeg or youtube-dl will raise a Nostrum.Error.VoiceError if Porcelain can't find the executable.

No ffmpeg

18:01:50.666 [warn]  ffmpeeeg was not found in your path. Nostrum requires ffmpeg to use voice.
If you don't intend to use voice, configure :nostrum, :ffmpeg to nil to suppress.

ffmpeg without youtube-dl

18:18:35.457 [warn]  youtube-dlll was not found in your path. Nostrum supports youtube-dl for voice.
If you don't require youtube-dl support, configure :nostrum, :youtubedl to nil to suppress.

Voice.play/3 without ffmpeg

17:48:07.207 [error] Task #PID<0.343.0> started from #PID<0.327.0> terminating
** (Nostrum.Error.VoiceError) ERROR: Command not found: ffmpeeeg - ffmpeg improperly configured
    (nostrum 0.4.4) lib/nostrum/voice/audio.ex:166: Nostrum.Voice.Audio.spawn_ffmpeg/2
    (nostrum 0.4.4) lib/nostrum/voice.ex:132: Nostrum.Voice.play/3
    ....

If the play/3 call was issued by a consumer, which will be the most common use case, the error will pop 4 times if uncaught since the started under the ConsumerSupervisor. I guess this is the intended behaviour.

[BrandtHill]

End of input will be automatically detected for playing audio with pipe/ytdl. :VOICE_SPEAKING_UPDATE events will be emitted when sound starts or stops.

[Kraigie]

How does this work? If someone plays a short song (under 20s) will we not send the event until after the 20s has elapsed? Or is this for some other functionality entirely? Not sure what stalling means in this context!

[BrandtHill]

Stalling occurs when the ffmpeg process stays open waiting for data to be piped into stdin. Calling Enum.take/2 on the process's output stream will hang indefinitely in this case. When playing from a url/file, ffmpeg closes automatically and a "stall" never occurs. The 20 second init timer means that if we are just beginning to play a sound, allow up to 20 seconds for ffmpeg, youtube-dl, or whatever source you might use with :pipe option, to download/buffer data from the source to start playing. Otherwise, if we're already playing audio (init? == false) only wait 200 milliseconds until we consider ffmpeg to have stalled. This is how we detect our non-url source has terminated, as this isn't required when using :url option. On stall, we simply close the ffmpeg process, and this allows the Enum.take/2 call to continue, and the player process will exit normally. If playing a short audio sample, from youtube-dl for example, after the first burst of frames, all subsequent watchdogs will have the 200 millisecond timer, so the event will be sent right as we detect the audio concludes.

[Kraigie]

Thanks!