MeteorLight

Radio streamer (kawa drop-in compatible).

This project is a Work in Progress.

TODO: proper handling of audio queue <-> data queue, timeouts, ICY metadata

Improvements / differences from Kawa

• Does not use libav (see supported formats/codecs on Kirika)
• Supports HTTP clients that have more than 16 HTTP request headers.
• Does not restart stream per-track, instead being a continuous stream without parameter changes.
• Normalized channels / sample rates for mounts.
• Implements ICY metadata
• Uses sample/timed packet buffers, instead of kawa byte buffers, which cause wild differences between endpoints. Mounts usually align within 0.2s of each other, depending on client.

Dependencies

Go >= 1.18

Kirika dependencies

Kirika is a collection of audio utilities for decoding/encoding files and streams.

Check its native dependencies that must be installed before usage.

Usage

Start by copying example_config.toml to the location of your choice and reading through it. Of importance are queue.fallback, and queue.random_song_api.

MeteorLight will search for config.toml in its working directory. Alternatively you can pass -config "/example/path/config.toml" to specify a different location.

Batteries are not included - MeteorLight needs to be paired with your own software to find songs to stream. You will have to provide an external API that MeteorLight can query for songs to play and notify as new songs being played.

Before continuing, you will need to install the dependencies listed above.

From Git repository

$ git clone https://git.gammaspectra.live/S.O.N.G/MeteorLight.git && cd MeteorLight
$ go run . 

From Go run

$ go run git.gammaspectra.live/S.O.N.G/MeteorLight@<commit_hash>

API

See kawa API for a general overview. Additional endpoints or changed ones are listed below.

Track blobs returned have a queue_id parameter, regardless of source.

NEW DELETE /queue/<queue_id>

Unqueues the track with queue_id specified as a parameter.

Response

{
    "success": true,
    "reason": null
}

CHANGED POST /queue/head

Same as kawa's, but queue_id is added to response directly.

Response

{
    "success": true,
    "reason": null,
    "queue_id": 3
}

CHANGED POST /queue/tail

Same as kawa's, but queue_id is added to response directly.

Response

{
    "success": true,
    "reason": null,
    "queue_id": 5
}