Skip to main content
Rockbox reads ~/.config/rockbox.org/settings.toml once on startup. Edit the file, then rockbox restart. There is no live-reload; the API is the way to change things at runtime.

Minimal config

music_dir is the only required field. audio_output defaults to "builtin" (CPAL) if omitted.

Top-level keys

Output sinks

Each sink has its own configuration block. See the dedicated pages:

Built-in (CPAL)

Default. No setup.

Snapcast

FIFO or direct TCP.

AirPlay

Single or multi-room RAOP.

Squeezelite

Slim Protocol multi-room.

Chromecast

Google Cast over WAV/HTTP.

UPnP / DLNA

Sink, server, renderer.

Playback defaults

Equalizer

The full 10-band parametric EQ is documented in Audio settings › Equalizer.

Crossfade

Tone & stereo

ReplayGain

Compressor

HTTP file cache

Rockbox caches remote audio files on disk so repeat plays are instant and require zero network traffic. Files are downloaded in the background in parallel range-request parts so the cache is populated without any interruption to the live stream.

How it works

Stream / radio protection

The cache automatically skips URLs that have no Content-Length — infinite streams (ICY radio, HLS) never produce one, so they are never queued for caching. For URLs that do return a Content-Length but should still be skipped (e.g. a CDN-delivered live stream), add a matching substring to cache_no_cache_patterns.

Key derivation

Each cached URL is stored as SHA-256(url).cache in cache_dir. The hash is deterministic and URL-specific, so query-string variations produce distinct cache entries.

Parallel download

Files ≥ 2 MB are split into cache_parallel_parts equal byte ranges and fetched concurrently. Each thread writes directly to its allocated region of a pre-allocated file via pwrite (Unix) / seek_write (Windows), so threads never contend. Set cache_parallel_parts = 1 to fall back to single-connection downloads. If any range request fails (e.g. the server returns 200 instead of 206), the whole file is re-fetched sequentially as a fallback.

Where settings come from

There are three layers, in order of precedence:
  1. Runtime API calls — every setting is also exposed over GraphQL/gRPC and persists to disk on the next save cycle.
  2. settings.toml — applied once at startup.
  3. Compiled-in defaults — in apps/settings_list.c.
For the full settings catalogue with units, ranges and where each one is applied, see the Settings TOML reference.