Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Provide a way of physically changing volume
See original GitHub issueIs your feature request related to a problem? Please describe.
There is currently no way of physically changing volume. The only way of doing it is through the environment variable SYSTEM_OUTPUT_VOLUME which requires dashboard access and triggers service restarts.
Describe the solution you’d like Ability to control master volume by using a rotary encoder/knob via GPIO.
Additional context I have already implemented this feature but the results are nowhere near acceptable since the feedback loop when changing volume is too long. Rotating the knob modifies the environment variable, which triggers a service restart. This takes well over 30 seconds, so it’s not usable.
This feature will have to wait for the next iteration of balenaSound where volume control is redesigned.
Issue Analytics
- State:
- Created 3 years ago
- Comments:5 (2 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
@AlexProgrammerDE, yes and no 😆 Let me share a bit of context…
We are discussing internally what the next major version of sound will look like. One of the main goals we have is to try and decouple the audio sources from the features. This means that we want to be able to add a new audio source (stream audio from X service) and instantly benefit from all the existing features (GPIO control, volume control, multi-room, scripts, etc) without having to change much.
The idea is we will have a central service that will handle “audio” features, then we will have what we are calling “plugins” (bluetooth, spotify and airplay currently). Plugins will send audio to this central service, then all operations will be made to the “audio” container. So volume control, GPIO, multi-room, scripts, all the features will only interact with the audio service. This will greatly simplify the “plugins” and also the rest of the logic.
So what you say is exactly what we want, a global implementation of volume control. But we are not sure yet what this central audio will look like or how to interact with it, so it’s best if we hold on a bit on that so that we (you) don’t work on something that then is not used.
I wrote a first draft document outlying all this, I’m happy to share it with you once it’s more finalised so you can check it out.
[kenna-smith] This issue has attached support thread https://jel.ly.fish/e59609d2-7937-441c-b026-57b33c8b8c06