giof71/audirvana-docker

Purpose and Entry Points

This repository builds and runs self-built Docker images for proprietary Audirvana Studio or Audirvana Origin on Linux amd64 and arm64 hosts. It deliberately does not distribute images containing Audirvana binaries.

Primary operator entry points are build-origin.sh, build-studio.sh, and Compose startup through docker-compose.yaml. Builder-enabled alternatives are docker-compose-origin.yaml and docker-compose-studio.yaml.

Image Build Pipeline

The common image recipe is build/Dockerfile. Root build scripts select the desired Audirvana variant and invoke Docker image builds:

• build-origin.sh

• build-studio.sh

• build/Dockerfile

The build incorporates the current proprietary application binary into a locally produced image. Rebuilding is the intended update mechanism when Audirvana releases a new version.

Container Bootstrap and Application Installation

The image contains an application-management script set under build/app/bin/. Installation is separated from normal execution, reflecting the design choice to install binaries during image build rather than incur startup-time download/install latency.

Key stages are represented by:

• build/app/bin/install-dep.sh — installs runtime dependencies.

• build/app/bin/install-util.sh — installs supporting utilities.

• build/app/bin/install-app.sh — installs the selected Audirvana application.

• build/app/bin/cleanup.sh — removes build/install artifacts.

• build/app/bin/run.sh — container runtime launcher.

build/Dockerfile orchestrates these scripts into the final runtime image.

Variant Selection Boundary

Audirvana type is an explicit configuration boundary: BINARY_TYPE must identify studio or origin. Dedicated build scripts and Compose files provide ergonomic paths for each variant, while the generic Compose path expects the configured image/application selection.

Relevant paths:

• build-origin.sh

• build-studio.sh

• docker-compose-origin.yaml

• docker-compose-studio.yaml

• docker-compose.yaml

Runtime Configuration and Host Integration

Compose injects runtime settings from a local .env, seeded from sample.env. The principal boundary is between the containerized service and host-owned identity, audio devices, and music storage:

• PUID / PGID run the application under a host-compatible user.

• AUDIO_GID grants optional access to host ALSA/audio-group resources.

• MUSIC_DIRECTORY is mounted into the container at /music.

• ACCEPT_EULA is an explicit mandatory gate.

Paths: sample.env, docker-compose.yaml, music/.placeholder.

Infrastructure and External Dependencies

Docker and Docker Compose are required on the host; the repository targets Linux systems, including 64-bit Raspberry Pi environments. The container depends on Audirvana-provided binaries obtained during local build and may use host audio hardware through ALSA-related group access. At runtime, Audirvana can act as a music server/controller and can integrate with external UPnP renderers; renderer services are not implemented in this repository.

Operational Flow

1. Operator configures .env from sample.env, including EULA acceptance, app type, host IDs, and music mount.

2. Operator builds a Studio or Origin image via root scripts, or lets the variant-specific Compose file build it.

3. Docker executes build/Dockerfile, installs dependencies/utilities and the selected Audirvana binary, then cleans intermediate artifacts.

4. Compose starts the container; build/app/bin/run.sh launches Audirvana using mounted music and optional host audio access.