Skip to content

Home


A lightweight, native voice implementation for hikari-based Discord bots


Overview

hikari-wave is a standalone voice module for hikari that provides direct voice gateway communication without requiring external backends like Lavalink.

It is designed to be:

  • Simple to use
  • Fully asynchronous
  • Native to hikari's architecture

No separate software. No complex setup. Just voice.

Contents

Features

  • Native Discord voice gateway implementation
  • Async-first, awaitable API
  • Strong typing and documentation throughout (Pylance/MyPy friendly)
  • Supplemental voice events for better control and UX
  • No external services (no Lavalink, no JVM, etc.)
  • Designed specifically for hikari's async model
  • Minimal overhead and predictable behavior

Installation

pip install hikari-wave

Ensure FFmpeg is installed and available in your system PATH.

Quick Start

Create a basic voice client bot:

import hikari

bot = hikari.GatewayBot("TOKEN")
voice = hikariwave.VoiceClient(bot)

bot.run()

Connect to a channel and play audio when you join a channel:

@bot.listen()
async def on_join(event: hikariwave.MemberJoinEvent):
    connection = await voice.connect(event.guild_id, event.channel_id)
    source = FileAudioSource("test.mp3")

    await connection.player.play(source)

That's it.

Implemented Features

  • [X] Voice connect / disconnect
  • [X] Audio playback
  • [X] Move, reconnect, resume
  • [X] Player utilities (queue, shuffle, next/previous, volume, etc.)
  • Audio Sources:
    • [X] Files
    • [X] URLs
    • [X] In-memory buffers
    • [X] YouTube
  • [X] Discord Audio/Video End-to-End Encryption (DAVE)

Library Lifecycle

See https://hikari-wave.wildevstudios.net/en/latest/pages/lifecycle for the full list of deprecated and experimental features.

Help and Contact

Feel free to join the hikari Discord server under the #wave channel for assistance.

Versioning & Stability Policy

hikari-wave follows Semantic Versioning with a clear and practical stability model designed to balance rapid development with reliability.

Version Format

MAJOR.MINOR.PATCH

Patch Releases (x.y.z)

  • Bug fixes and internal improvements only
  • No breaking changes
  • Always considered stable
  • No alpha (a) or beta (b) suffixes

Patch releases are safe to upgrade to without code changes.

Minor Releases (x.y.0)

  • Introduce new features, subsystems, or configuration options
  • Existing public APIs generally preserved, but behavior may expand
  • May include short-lived alpha/beta pre-releases before stabilization

Example releases flow: 1.0.0a1 -> 1.0.0b1 -> 1.0.0 -> 1.0.1 Pre-releases exist to gather feedback and catch issues early. Once stabilized, the same version is released as a stable minor.

Pre-Releases (a/b)

  • Used only for new minor/major versions
  • Intended for developers who want early access to new features/versions
  • Not recommended for production unless you are testing upcoming functionality

Recommendation

If you want maximum stability:

  • Pin to stable releases
  • Avoid alpha/beta versions

If you want early access to new features:

  • Opt into pre-releases and report issues

Deprecation Policy

To ensure stability while allowing hikari-wave to evolve, the project follows a structured and transparent deprecation process.

What is considered deprecated?

A feature may be deprecated if it:

  • Has a better or more flexible replacement
  • Causes long-term maintenance or performance issues
  • Conflicts with newer architectural changes

Deprecation Process

When a feature is deprecated:

  1. Explicit Announcement

  2. The deprecation is documented in:

    • The changelog
    • The documentation (API docs)

  3. A clear migration path is provided when possible

  4. Runtime Warnings

  5. Deprecated features may emit a DeprecationWarning

  6. Warnings are non-fatal and do not break existing code

Removal Timeline

  • Pre-1.0.0
    • Breaking removals may occur at any time
    • Deprecations will still receive advance notice whenever possible
  • 1.0.0+
    • Deprecated features will not be removed until the next major version

Experimental Features

  • APIs marked as experimental are exempt from the deprecation process
  • Experimental features may change or be removed without notice
  • Experimental status will always be clearly documented

User Responsibility

Users are encouraged to:

  • Monitor release notes and changelogs
  • Address deprecation warnings promptly
  • Test against pre-releases when relying on newer or evolving features

Contributing

Bug reports and feature requests are welcome via GitHub Issues. Clear reproduction steps and context are appreciated.

License

MIT License © 2025 WilDev Studios