Feature: add --volume-controller, which enables LVA to use pipewire for master volume control. USB audio natively with LVA!#272
Conversation
GitHub Actions
Failure
|
Thank you for putting this behind a flag - I would not want the default behavior to be changing hardware device volume, because I share that hardware device with multiple applications that each need a different volume level |
|
Yup! I need only libmpv volume for my setup. But good option to have. |
|
While seeing the need for this feature i rather want to have it as an addon. We want to make the code more modular and i would like to move this into the backlog until we have that done. |
i get that, but since modifying the calls to libmpv code is a bit invasive (since i have to prevent calls to libmpv's volume!), it would be hard to do this purely modularly. it is behind a flag that is off by default after all. unless the set_volume function (which didn't even fully exist till i added it) could be pulled out and overridden, this would be hard to modularize |
|
We're working on sending external commands to LVA that can control volume, so wouldn't this one help? #266 |
# Conflicts: # Dockerfile # linux_voice_assistant/entity.py
GitHub Actions
Inactive
|
ok these new commits make it so it doesn't depend on wireplumber anymore, it purely uses |
# Conflicts: # README.md # docker-entrypoint.sh # docs/additional_audio_settings.md # docs/install_application.md # linux_voice_assistant/__main__.py
GitHub Actions
Inactive
GitHub Actions
Inactive
|
I don't think writing the pactl output to stdout is the right long-term approach. Instead, we should introduce a proper abstraction for audio device management and use a library/API to query and control PulseAudio/PipeWire directly. That would be more robust, easier to maintain, and avoids relying on parsing command output. I'd prefer to solve this in a follow-up by adding a dedicated library-based implementation rather than extending the stdout approach. |
| # a bit verbose but otherwise robust and awk/grep/regex-less | ||
| # no get-sink-volume does not support -f json, otherwise i would have DONE that | ||
| def_sink = await get_stdout("pactl", "get-default-sink") | ||
| sinks = json.loads(await get_stdout("pactl", "-f", "json", "list", "sinks")) |
There was a problem hiding this comment.
I don't think writing the pactl output to stdout is the right long-term approach.
|
My feedback on this is that it will affect the MPV media player volume. So we should keep the system volume itself always at maximum in order to have free control of the media player via the HA entity. |
Not doing this is the entire point of this pull request, and why it's disabled by default, and why this PR makes the HA entity reflect the system volume The idea is by changing the system volume, specific USB hardware devices will be able to read and write to that volume |
If I remember right, I chose the stdout approach to avoid adding another dependency I can look into libraries. Do you know of any? |
|
You can keep the system volume itself at maximum to just control the media player entity, like everybody does, rather than limiting the mpv player volume by hard control. |
Right, which is still the default behavior. |
florian-asche
left a comment
florian-asche
left a comment
There was a problem hiding this comment.
Need changes here
5 participants
instead of setting libmpv volumes, it sets the external pipewire sink directly. the main benefit of this is that pipewire integrates with ALSA which integrates with USB devices, so you can look at and see changes to the LVA volume from USB audio devices
demo:
PXL_20260327_214123047.mp4