search

balena-io-experimental / balena-sound

Build a single or multi-room streamer for an existing audio device using a Raspberry Pi! Supports Bluetooth, Airplay and Spotify Connect
https://balena.io/blog/turn-your-old-speakers-or-hi-fi-into-bluetooth-receivers-using-only-a-raspberry-pi/
MIT License
2.39k stars 427 forks source link

Provide a way of physically changing volume #195

Open tmigone opened 4 years ago

tmigone commented 4 years ago

Is 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.

jellyfish-bot commented 4 years ago

[tmigone] This issue has attached support thread https://jel.ly.fish/#/f1ca0623-af4b-4062-905b-c92bedcab7cf

AlexProgrammerDE commented 4 years ago

@tmigone i already use some GPIO volume changing code in my bluetooth-control PR. Shall i try to implement that globally?

tmigone commented 4 years ago

@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.

ChestersGarage commented 3 years ago

I have been able to use any snapcast client to change audio volumes per server and per client individually. Works on Windows, Mac and Android so far. But I can't seem to find a snapcast client for iPhone. I'd suggest looking into coupling the physical volume control to the snapcast volume. It's instantaneous - no lag at all - and very smooth.

jellyfish-bot commented 3 years ago

[kenna-smith] This issue has attached support thread https://jel.ly.fish/e59609d2-7937-441c-b026-57b33c8b8c06