nostrum
nostrum copied to clipboard
Crazy idea: Make voice dependencies optional
- Add
optional: true
inmix.exs
- Voice users need to include voice dependencies in addition to existing dependencies
Would be happy to hear feedback here.
Thoughts on this @Kraigie?


@jchristgit seems to like it:
Craizy
I'm okay with either approach. It seems like the more idiomatic approach would be to make them optional in the dependency but 🤷
Just looking into voice myself. The API is a little opinionated, there are some situations where I'd prefer to send proxied RTP directly maybe with a little rewriting instead of being forced into the ffmpeg route. I know it would probably require the api to change, but wouldn't it be better to keep the core library just concerned with connection setup and RTP sending, leaving what's generating that actual audio to a separate package?
I think a solution that covers both would probably be the best option, right? I can't back this up with data, but I feel like the most common use case is the ffmpeg route and the implementation is frankly above most users of this library.
I don't see why we can't just have our own processing live on top of some core connection process. How does that sound? That way users who depend on the current functionality still can, but your use case is also supported.
I think this can be achieved by exposing the VoiceState
struct and a few private functions in the Voice
module that interact with it.
I assume the overwhelming majority of users aren't going to care about the implementation and just want a simple way to play audio files and youtube videos, which is provided by ffmpeg and youtube-dl.
Exposing the VoiceState
should give an enterprising RTP ninja everything they need to send their own audio packets, including UDP socket, IP/port, RTP timestamp/sequence, encryption key, etc.
@bbhoss Check out the new voice features to bypass ffmpeg available in master and 0.4.7 sometime soon.
The mix.exs
file has hanged quite a bit since this issue was created. Should this close or stay open? 😄
The need to make voice dependencies optional was probably overstated to begin with. The only voice-specific dependency now is :kcl
. It's a 2-module library that itself depends on four other single-module libraries.
I agree with @BrandtHill. I think when this issue was made we still had porcelain and some others? Closing.
Yes, we also had porcelain but now use erlang ports directly.