Skip to content

Standalone audio sending node based on Lavaplayer.

License

Notifications You must be signed in to change notification settings

jr-oszik/Lavalink

 
 

Repository files navigation

Lavalink

A standalone audio sending node based on Lavaplayer and Koe. Allows for sending audio without it ever reaching any of your shards.

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

A basic example bot is available.

JDA guild

Features

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

Requirements

  • Java 11* LTS or newer required.
  • OpenJDK or Zulu running on Linux AMD64 is officially supported.

Support for Darwin (Mac), Windows AMD64, and Linux ARM (Raspberry Pi) is provided on a best-effort basis. This is dependent on Lavaplayer's native libraries.

Lavaplayer currently supports following architectures:

Darwin (M1 & Intel), Linux aarch32, Linux aarch64, Linux ARMv7+ 32/64, Linux ARMHF(v6) 32, Linux i386 32, Linux x86 64, Windows i386 32 and Windows x86 64

JDA-NAS(Native Audio Buffer) & the Timescale filter are currently not supported on following architectures:

Linux ARMHF(v6) 32 and Linux aarch32

Support for other JVMs is also best-effort. Periodic CPU utilization stats are prone not to work everywhere.

*Java 11 appears to have some issues with Discord's TLS 1.3. Java 14 has other undiagnosed HTTPS problems. Use Java 13. Docker images have been updated. See #258, #260

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.
  • A change that is breaking to one domain might not be breaking at all to another.

    Examples:

    • Removing an endpoint: This is a breaking change for the client domain but is not 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 committed to the client domain of Lavalink

    Examples: Removing an endpoint, altering the output of an endpoint in a non-backward-compatible manner

  • Major: Bumped when breaking changes are committed to the Lavalink server domain

    Examples: Bumping the required Java version, altering the configuration in a non-backward-compatible manner

  • Minor: New features in any domain

    Examples: New optional endpoint or opcode, 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 an optimum effort to adhere to Semantic Versioning, prepending it with an additional API version makes life easier for developers in two ways: It is a clear way for the Lavalink project to communicate the relevant breaking changes to client developers, and in return, client developers can use the API version to communicate to their users about the compatibility of their clients to the Lavalink server.

Client libraries:

Client Platform Compatible With Additional Information
Lavalink-Client Java JDA/Any
LavaClient Java JDA
Lavalink.kt Kotlin JDA/Kord/Any Kotlin Coroutines
Lavalink.py Python Any
lavasnek_rs Python Any* *asyncio-based libraries only
lavaplayer-py Python Any* *asyncio-based libraries only
Wavelink Python discord.py V2
Pomice Python discord.py V2
discord-ext-lava Python discord.py
Lavapy Python discord.py
Magma Python discord.py
Lavadeno Deno Any
LavaJS Node.js Any
erela.js Node.js Any
LavaClient Node.js Any
Lavacoffee Node.js Any
Lavacord Node.js Any
Moonlink.js Node.js Any
@skyra/audio Node.js discord.js Archived
Poru Node.js Any
Shoukaku Node.js Any
Lavaudio Node.js Any
Gorilink Node.js discord.js Archived/Unmaintained
SandySounds Node.js Any Unmaintained
eris-lavalink Node.js eris Unmaintained
Victoria .NET Discord.Net
Lavalink4NET .NET Discord.Net/DSharpPlus
DSharpPlus.Lavalink .NET DSharpPlus
Lavalink.NET .NET Any Unmaintained
SharpLink .NET Discord.Net Unmaintained
DisCatSharp.Lavalink .NET DisCatSharp
disgolink Go Disgo/DiscordGo/Any
waterlink Go Any
gavalink Go Any Unmaintained
Lavalink-rs Rust Any* *tokio-based libraries only

Or alternatively, you can create your own client library, following the implementation documentation. Any client libraries marked with Unmaintained have been marked as such as their repositories have not received any commits for at least 1 year since time of checking, however they are listed as they may still support Lavalink, and/or have not needed maintenance, however keep in mind that compatibility and full feature support is not guaranteed.

Server configuration

Download binaries from the GitHub actions or the GitHub releases(specific versions prior to v3.5 can be found in the CI Server).

Put an application.yml file in your working directory. (Example here)

Run with java -jar Lavalink.jar

Docker images are available on the Docker Hub.

Docker Pulls

About

Standalone audio sending node based on Lavaplayer.

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • Kotlin 54.4%
  • Java 45.4%
  • Dockerfile 0.2%