minndevelopment/lavalink

Standalone audio sending node based on Lavaplayer and JDA-Audio.

Lavalink

Standalone audio sending node based on Lavaplayer and JDA-Audio. Allows for sending audio without it ever reaching any of your shards.

Being used in production by FredBoat, Dyno, Rythm, LewdBot, and more.

Features

• Powered by Lavaplayer
• Minimal CPU/memory footprint
• Twitch/YouTube stream support
• Event system
• Seeking
• Volume control
• REST API for resolving lavaplayer tracks (used for non-JVM clients)
• Statistics (good for load balancing)
• Basic authentication
• Prometheus metrics
• Docker images

Changelog

Please see here

Versioning policy

The public api ("api" in a very broad sense) of Lavalink can be categorized into two main domains:

• Client Domain: The api exposed to clients, consisting of both the websocket protocol, and any public http endpoints
• Server Domain: The server application with its runtime environment, its configuration, etc.

Changes that might be breaking to one domain need not be breaking to the other. Examples:

• Removing an endpoint. This is a breaking change for the client domain, but is not a breaking change for running the server itself.
• Upgrading the minimum Java version: This is a breaking change for the server domain, but client implementations couldn't care less about it.

Given the above, the following versioning pattern lends itself well to the Lavalink project:

api.major.minor.patch

• Api: Bumped when breaking changes are comitted to the client domain of Lavalink
  Examples: Removing an endpoint, altering output of an endpoint in a non backwards compatible manner
• Major: Bumped when breaking changes are comitted to the Lavalink server domain
  Examples: Bumping the required Java version, altering the configuration in a non backwards compatible manner
• Minor: New features in any domain Examples: New optional endpoint or op code, additional configuration options, change of large subsystems or dependencies
• Patch: Bug fixes in any domain Examples: Fixing a race condition, fixing unexpected exceptions, fixing output that is not according to specs, etc.

While major, minor and patch will do a best effort to adhere to Semantic Versioning, prepending it with an additional api version makes life easier for developers of client implementations in two ways: It is a clear way for the Lavalink project to communicate the actually relevant breaking changes to client developers, and in turn, client developers can use the api version to clearly communicate to their users about the compatibility of their clients to the Lavalink server.

Client libraries:

Supports 3.x and older:

• Lavalink-Client (JDA or generic, Java)
• LavaClient (Java)
• Lavalink.py (discord.py, Python)
• pylava (discord.py, Python)
• SandySounds (JavaScript)
• eris-lavalink (eris, JavaScript)
• discord.js-lavalink (discord.js, JavaScript)
• SharpLink (Discord.Net, .NET)
• Victoria (Discord.NET, .NET)
• Lavalink.NET (.NET)
• DSharpPlus.Lavalink (DSharpPlus, .NET)
• Luna (Yasmin or generic, PHP)
• gavalink (Go)
• Magma (discord.py, Python)
• lavapotion (Elixir)
• Or create your own

Supports 2.x:

• eris-lavalink (Eris, JavaScript)
• discord.js-lavalink (Discord.js, JavaScript)
• Or create your own

Server configuration

Download binaries from the CI server or the GitHub releases.

Put an application.yml file in your working directory. Example

Run with java -jar Lavalink.jar

Docker images are available on the Docker hub.

Acknowledgements

This project contains modified code from https://github.com/sedmelluq/jda-nas v1.0.5