Skip to content

Reduce media player state complexity and document sound system behaviour #682

Closed

Description

@GreenGrassBlueOcean

Problem

The WHO 16 sound system implementation has grown into a complex state machine spread across multiple modules (media_player.py, media_player_group.py, media_player_decoder.py, media_player_source.py, etc.). While the modular split improved readability, the interaction between power state, volume reports, intercom ducking, multi-room grouping and anti-hiss auto-off remains difficult to reason about and has caused multiple regressions.

Recent examples:

Current architecture

The entity is built as a layered chain:

  • ZoneBase
  • Source routing
  • Decoder mirroring + anti-hiss
  • Group join/leave/park/wake
  • Final entity

Power state can be influenced by explicit ON/OFF frames, volume rocker commands, dimension 1 volume reports, decoder state changes and group membership. The rules that decide when an amplifier should be considered on or off are distributed across these layers.

Proposal

  1. Document the state machine

    • Add a concise state diagram (or decision table) to the sound system documentation that shows which frames and events may change power state.
    • Explicitly list frames that must never change power state (e.g. dimension 1 volume status reports).
  2. Centralise power-state decisions

    • Consider extracting the power-state logic into a single, well-tested helper or mixin so that the rules are not duplicated or overridden in multiple layers.
  3. Expand regression coverage

  4. Clarify user-facing behaviour

    • Document known interactions between video door entry and the sound system (ducking, temporary volume changes).

Acceptance criteria

  • Documentation contains a clear description or diagram of when an amplifier entity changes power state
  • Dimension 1 volume status reports cannot turn an off amplifier on
  • Golden trace tests cover intercom ducking and group park/resume
  • No new regressions in existing media player tests

Related


Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions