Files

Martin Bauer 804cb1bfaf Give musicdolphin real sound through the HifiBerry amp

It was set up display-only, with alsa_device "simulate", so the UI showed a
working player that made no noise - but the Pi has a HifiBerry amp and
pi_alsasetup already put the softvol_effects slot on it. Point the backend at
it, the same way musicmouse does: a softvol control feeding dmix, so the card
stays shared with squeezelite and shairport instead of being locked.

Carry musicmouse's volume clamp over with it. Below roughly 23 the softvol
attenuation leaves nothing audible, and the ceiling keeps a UI slider from
putting the amp to full. Those numbers are tuned to musicmouse's speakers and
this is a different room, so they are a starting point.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-09-19 21:53:50 +02:00

defaults

Build the venv from the distribution's Python instead of uv

2026-09-19 21:21:12 +02:00

files

Give musicdolphin real sound through the HifiBerry amp

2026-09-19 21:53:50 +02:00

handlers

Only restart samba when its config changes

2026-09-19 21:41:50 +02:00

tasks

Only restart samba when its config changes

2026-09-19 21:41:50 +02:00

README.md

Build the venv from the distribution's Python instead of uv

2026-09-19 21:21:12 +02:00

README.md

pi_musicmouse

Deploys the MusicMouse backend (python-backend/) and its built web frontend.

Checks out musicmouse_version from pi_musicmouse_repo to /opt/musicmouse, then fails early if that checkout has no python-backend/pyproject.toml - see "Which version" below.
Creates /opt/musicmouse/.venv from the distribution's own python3 and pip-installs the backend into it. The backend targets the Python that Raspberry Pi OS ships (3.11 on Bookworm) precisely so this step stays boring: apt and piwheels have prebuilt armhf wheels for the native dependencies, so nothing has to be compiled on the Pi. If the venv was built by a different interpreter than the current python3, it is thrown away and rebuilt.
Builds the frontend (web/) on the control machine (delegated to localhost, not the Pi - no Node/npm is installed on the Pi) and syncs web/dist over.
Installs /media/musicmouse/config.yml from files/config-<inventory_hostname>.yml (one file per host - the schema differs between a host with a real mouse attached and a display-only one; see those files' own comments), the typing game's curriculum beside it, and the systemd unit copied straight from the checked-out repo's python-backend/musicmouse.service, so it can never drift from what's actually in the app repo.
Sets up a Samba share of /media/musicmouse for copying music onto the device.

Which version

musicmouse_version is set per host in host_vars, with no default, and points at a deploy/<host> branch on the remote. Those branches are the deployment record: what is installed on that box right now. Moving one is a force-push, and the next run follows it (the git: task uses force: true):

git push -f origin rearchitect-backend:deploy/musicdolphin
just mediapis musicdolphin

This role only understands the post-rearchitecture layout - python-backend/ as an installable package plus a web/ frontend. On older commits the host driver lives at espmusicmouse/host_driver/main.py, there is no pyproject.toml, the unit file is under esp-firmware/, there is no frontend at all, and the config is a different format that this role's config files would fail to load. There is deliberately no legacy path: the role stops at the checkout with an explanation instead.

musicmouse (Kinderzimmer) is on such an older commit and still working, so it has mediapi_install_kidsmusic: false and this role skips it entirely; deploy/musicmouse exists purely as the rollback marker for what is installed there. Migrating it means moving /media/musicmouse/<figure>/ into Figuren/ and switching to the new config schema - files/config-musicmouse.yml is already written for that.

config.yml is install-once

The app writes to its own config at runtime: parent mode (?parentMode=1) patches the volume keys, and the remote-control page rewrites the whole remote: block. A plain copy: would throw those away on every ansible run, so the config task is force: "{{ pi_musicmouse_force_config }}", default false. Push a changed config when you actually mean to:

just run mediapis.yml musicdolphin -e pi_musicmouse_force_config=true

The curriculum file is not written by the app, so it is installed unconditionally. A config with a tippen: section will not start without it - curriculum_file is validated as must-exist - so a host whose config has no tippen: section should set pi_musicmouse_curriculum_file: "".

Manual steps after a first deploy

Set the Samba password with smbpasswd.
Get the music onto the device. The app repo's scripts/sync-library.sh is the way to do it: as well as the library it carries over the cover and track-analysis cache, which is the part that costs minutes of DSP per track to recompute, and it knows which parts of that cache survive the move and which must not be copied. The Samba share works too, and then the device does all that work itself.