using it

Sonn Client

A Raspberry Pi, or any comparable Linux box, turned into part of the audio system with one command. It holds no settings of its own: it reports the hardware it has, and what that hardware is used for is decided here, on the server.

curl -fsSL https://raw.githubusercontent.com/sonn-audio/sonn-client/main/install.sh | sudo bash

That is the whole device-side setup. The client finds the server on the network, registers, lists the sound cards it can play through and record from, and waits to be given a room. It appears under Setup → Sonn Client the moment it does.

Four jobs, all optional

job	what it does
Speaker	Plays a room. One player per sound card, so a Pi with two DACs serves two rooms.
Input	Listens to a turntable, a CD player, anything with a line out, and offers it as a source any room can select.
Bluetooth	Takes a phone: pairs it, receives the audio, and hands it to a room as an ordinary input.
Remote	Serves the menu on a Beoremote One and forwards the keys of it and of a Beoremote Essence.

They are independent of one another. The Pi at the record player can do the input and the Bluetooth with no speaker attached at all, while the room that audio ends up in is a different box across the house. A box with nothing but a DAC does only the speaker. You pick per device, in the Admin UI.

The speaker

Playback is Sendspin and nothing else, on purpose. AirPlay, Spotify Connect, Chromecast and DLNA all still reach a room driven by this client — they are terminated on the server, which turns them into one stream aimed at the device. One protocol on the device means one clock, one buffer model, one place where synchronisation is solved; a second playback protocol would be a second answer to "when should this sample be heard", and there is no good second answer.

It is also the output where the file can arrive untouched. The client announces which rates and depths its card accepts, the server picks the format per track, and a 24-bit/192 kHz FLAC travels as itself. A Pi with a USB DAC is the shortest bit-perfect path this server has.

Volume goes to the sound card's own mixer where the card has one, with the software mixer left at unity — attenuating twice costs resolution and makes the slider behave oddly. Per speaker you can force this either way, or point it at a script for an amplifier with a volume of its own.

The input

A capture device on the Pi becomes a line-in the whole house can select: a turntable in the study, a CD player beside the amplifier. The client reports the level, so the server can tell that someone has started playing, and the room follows.

A line-in is not tied to the room its wire reaches. It is a source, and any zone can select it — which is why the Pi at the turntable needs no speaker of its own.

Bluetooth

Switch it on for a room and the device becomes discoverable under that room's name. A phone pairs with it, and what it plays arrives as an ordinary source: title, artist, album and the position on the phone's own timeline come with it, the phone's volume slider drives the room, and the room's name shows on the phone.

This is the one thing that must sit in the room itself — a phone's radio does not reach the cupboard where the server lives. What leaves the client is plain audio, announced exactly like the turntable next to it, so nothing about the playback side changes.

Cover art does not come across. The phone offers it, but the Bluetooth stack on Linux never asks for it — so the room shows the title, the artist and the album, and the artwork stays on the phone.

Bang & Olufsen remotes

This is the helper the Beoremote One pairs with. The client serves the remote's own service over stock BlueZ — no vendor daemon, no patched Bluetooth stack — so the menu the server builds appears on the remote's screen, and its keys and picks come back here. A Beoremote Essence works too, with its five fixed buttons: play/pause, skip, volume and mute.

Pairing is a button in the Admin UI, on the room the remote belongs to. Volume is applied on the device, so it keeps working while the server is briefly away.

Which server it attaches to

The client discovers audioservers over mDNS and attaches to what it finds. With more than one on the network, name the one you want in /etc/sonn-client/config.toml:

preferred_server_name = "Living room"   # the name the server advertises
# or, where mDNS does not cross a VLAN:
server_url = "http://192.168.1.20:7090"

Those select rather than suggest: with a preference set, no other server is used, and the choice it made is in the log at startup — so "the setting did not take" and "the server is not there" do not look alike.

Keeping it up to date

The server publishes a client version and the devices install it themselves, verified against a checksum, and never while the room is playing. Under Setup → Sonn Client you see what every box runs and can set the version for all of them at once.

When something is wrong

The device page has a Fetch log button: the client keeps its last few hundred lines in memory and hands them over when asked, so you can read what a speaker in another room has been saying without an SSH session. On the device itself:

journalctl -u sonn-client -f
sonn-client devices            # the sound cards the server is offered
sonn-client devices --log-level debug   # ...including the ones left out, and why

A device that has vanished from the Admin UI has usually been given a new identity — a fresh install generates one. The old entry stays until you remove it, because a speaker that is merely unplugged should not take its room's settings with it.