Match selected device for hardware volume

[abmantis]

Fixes #156

[Copilot]

Pull request overview

Updates hardware volume control to target the PulseAudio/PipeWire sink that corresponds to the user-selected PortAudio output device, addressing cases where system-created sinks (e.g., PipeWire) were being controlled instead of the intended ALSA device (Fixes #156).

Changes:

• Add sink selection logic that matches PulseAudio sinks to the selected PortAudio AudioDevice.
• Thread the resolved audio_device through CLI startup and into the HardwareVolumeController.
• Disable hardware volume at startup when PulseAudio is unreachable or no sink matches the selected device.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
sendspin/hardware_volume.py	Adds sink-matching helpers and switches controller operations to use the sink corresponding to the selected audio device.
sendspin/cli.py	Resolves the audio device once, uses it for hardware-volume availability checks, and passes it into daemon startup.
sendspin/audio_connector.py	Instantiates HardwareVolumeController with the selected audio_device.

Comments suppressed due to low confidence (1)

sendspin/hardware_volume.py:47

• async_check_available now returns False not only when PulseAudio is unreachable, but also when no sink matches the selected audio_device. The docstring still describes this as purely a connectivity check, which is now misleading; please update it to reflect the sink-matching requirement (or rename the function to better match the new semantics).

async def async_check_available(audio_device: AudioDevice, timeout: float = 2.0) -> bool:
    """Check if PulseAudio is actually reachable at runtime.

    Returns True only if we can connect to the PulseAudio server.
    This goes beyond the module-level AVAILABLE check (which only verifies
    the library is installed) by testing the actual connection. The check
    is bounded by *timeout* seconds to keep CLI startup responsive when
    PulseAudio is down or unreachable.
    """

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[maximmaxim345]

Tested on my Linux server.
I’m OK with merging this as a improvement, but selected-device hardware volume still falls back to software volume for some outputs on my setup.

[abmantis]

Tested on my Linux server. I’m OK with merging this as a improvement, but selected-device hardware volume still falls back to software volume for some outputs on my setup.

Yeah, some of those have no matching on my system too. Also, there are some that don't even have controls on alsamixer, much less on pipewire, while sound still plays trough them.

Oh, and for some reason device numbers on my system are also not stable across reboots.

My general recommendation for users would be to have pipewire properly setup and avoid --audio-device. Either set the device as default on pipewire, or just assign the app to the audio device (using pulsemixer, for example).

EDIT: changing the device on pipewire (with pulsemixer) does do it, since we don't follow pulse sinks and would use the default for hardware volume.

[balloob-travel]

Looks like this PR broke some things, we got a report on Discord: https://discord.com/channels/753947050995089438/1427434128403337337/1480649589534232576

Looked into it here, can you take a look? #177