volume control with 2.0.0

[juniormajor]

with the 2.0.0 upgrade and sendspin rework, i'm not sure, if i understand the function/logic correctly.
right now i have 1x ESPhome device with "media control incl volume" and 1x MusicAssistant sendspin player device with "media control incl volume". am i right that ESPHome is the announcment,... control, and the sendspin player is the real media player control? If so, i don't understand why the ESPhome volume reduces also the overall mediaplayer volume after a restart. guessing that preferences.yaml comes into play?
BR

[imonlinux]

Hey @juniormajor — good question, and your mental model is mostly right. Let me lay out exactly how the two entities relate in 2.0.0.

What each entity controls

• The media player HA shows via the ESPHome integration is LVA's own device entity. Its volume controls the assistant voice side: TTS responses, announcements, timers. Changes there are persisted to preferences.json (small correction: it's JSON, not yaml) as volume.
• The Music Assistant player (Sendspin) is the music path. Its slider is a separate software gain, persisted independently as sendspin_volume in the same file. The two sliders never write each other's values.

So yes: ESPHome entity = the device's voice/announcement control, MA player = the music control.

Why the MA player gets quieter after a restart

The two volumes are separate, but both audio paths end up at the same hardware output. If volume_sync is enabled, LVA pushes its persisted voice volume onto the OS sink (wpctl/pactl/amixer) at startup:

"audio": {
  "volume_sync": true
}

That's why you only see it after a restart: the Sendspin output plays through that same OS sink, and MA's slider is a client-side gain on top of it. Lower the ESPHome volume, reboot, and the sink comes up at that lower level — MA's own slider didn't move, but everything got audibly quieter.

Your options

• Want them fully independent? Set "volume_sync": false in the audio block (that's the default). LVA's volume then only scales its own players in software and never touches the OS sink.
• Want one master volume for the whole device? Keep volume_sync: true and treat the ESPHome entity as the master; the MA slider becomes a music-relative trim.

Can you check your config, try volume_sync: false, and reboot to confirm the MA player keeps its level? If that doesn't match what you're seeing, post your audio config block plus the startup log lines around sink volume, and I'll dig deeper.

One more intentional interaction to be aware of: while music plays, voice activity ducks it (coordination.duck_during_voice, gain 0.3 by default) — that one is momentary and restores automatically.

[juniormajor]

Understood, and confirmed. But then i don't understand why the WakeUp audio isn't reduced along the ESPHome integration entity.

[imonlinux]

Hey @juniormajor — Thanks for pointing that difference out. It was a deliberate "hard coded" override of the wake volume to address an issue posted upstream in OHF-Voice/linux-voice-assistant (OHF-Voice#290)

Why it was fixed: the wake chime is treated as a confirmation cue — "I heard you" — so it deliberately played at 100% regardless of the media player volume. The idea was that even if you run the satellite quiet, you still get an audible acknowledgment when the wake word triggers. Every other sound (TTS, thinking chime, timer alarm, mute sounds) follows the media player volume; the wake chime was the only outlier. But when you pointed it out, I thought "why not make it a configurable entity". After all, that is the point of this fork, let's make it work for us.

What's new: as of today, main has a Wake Volume Override number entity on the device page:

• 0 — no override: the chime follows the media player volume like every other sound (what you were expecting)
• 1-100 — the chime plays at that fixed level, regardless of the volume slider
• Default 100 keeps the old full-volume behavior, so existing installs sound exactly the same after updating

The value persists to preferences.json and survives restarts. If you provision headlessly, config.json takes a wake_volume key (or --wake-volume on the CLI) as the default until the entity is changed.

{
  "app": {
    "wake_volume": 40
  }
}

Update your device using script/update_lva (don't forget any extras like --sendspin if it is currently installed) and you should see the new entity on the device page. Set it to 0 and confirm the chime now tracks the volume slider the way you expected — feedback welcome, especially on how it feels at low volumes.

[juniormajor]

works like a charm! thx!