Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set hardware volume based on value in settings.ini. #309

Open
wants to merge 3 commits into
base: develop
Choose a base branch
from

Conversation

jcass77
Copy link
Member

@jcass77 jcass77 commented Jul 26, 2015

Not sure why the hardware volume has been hard-coded, it should be preferable to just use the values specified in settings.ini to avoid duplication.

@kingosticks
Copy link
Member

I looked at doing this previously but then I left it alone for some reason. Having thought again just now I think it's because I wasn't convinced this change was much better. As I see it, it's all a bit screwed up but maybe I've gotten confused in which case please help put me right.

By default we use Mopidy software volume and we also have the system's hardware volume. We stick hardware volume at 96% (and the Pi's onboard audio at 98% but let's ignore that) and the user can use audio/mixer_volume to set Mopidy's initial volume to whatever. Most user's come along with their speakers, try Mopidy first, might then decide it's too loud and set audio/mixer_volume=50. Afterwards they may tweak the (software) volume through their Mopidy client as they need and everything is great. Then they try Airplay, this just uses the hardware volume of 96% and is very loud, potentially damaging their hearing/speakers.

But with this change things are not much better, we now get the effect that setting audio/mixer_volume=50 limits the hardware volume to 50% (yay!) but Mopidy's initial volume becomes 25% (50% of 50%). IIRC we can't assume a linear scale so Airplay is potentially still much too loud. However, they could now use their Mopidy client to set the software volume to 100% (of 50%) but some people won't do this; they'll stick with a lower value, maybe they'll even decide it's too quiet and turn up the volume on their amplifier. When they switch to Airplay they may still be treated to a wildly different volume level.

I think what I'm saying is that we could make it clearer by having a separate hardware volume config setting rather than borrowing Mopidy's as it doesn't really make sense to do so.

Or, maybe ideally, we would set Mopidy to use hardware mixing (alsamixer) by default so that the audio/mixer_volume setting effected our hardware volume and we only ever have one volume to deal with. However, not all audio devices support hardware mixing, I think Hifiberry DAC is one example that doesn't, so then you've got a bunch of special cases that'll behave slightly oddly from the user's point of view. Or perhaps there is scope to make sure of ALSA's softvol plugin...

@jcass77
Copy link
Member Author

jcass77 commented Jul 26, 2015

I have been using hardware mixing (alsamixer) in Mopidy all along which is why I probably did not make a clear distinction between that and the system hardware volume - the explanation above helped a lot to understand this better, thank you.

I agree that having a separate hardware volume (e.g. musicbox/hardware_volume) setting is probably the best approach, but then the question becomes what happens if Mopidy is set to alsamixer as well, in which case it will just override whatever is specified in musicbox/hardware_volume when Mopidy starts up right?

I haven't fooled around with softvol yet, but based on my experience with alsaequal I'd say there is a high probability that it may cause sound distortion on most DAC's quite quickly.

@kingosticks
Copy link
Member

Yes I think so but that doesn't seem too bad. We could maybe have something in the startup script to ensure audio/mixer_volume is less than or equal to musicbox/hardware_volume. As long as websettings was very explicit about what the two config settings did I think that'd be OK.

I bet there is a whole world of elaborate ALSA plugin fun to be had but I'd really rather not. It's a shame though as it would be great to have everything at least appearing to have hardware mixing.

@kingosticks
Copy link
Member

I've just spent an age trying to get softvol to work but I don't get any audio, just error messages:

mopidy.audio.gst: GStreamer error: state change failed and some element failed to post a proper error message with the reason for the failure.

So I've lost all interest in that approach.

@jcass77
Copy link
Member Author

jcass77 commented Jul 29, 2015

The GStreamer error may have been my fault (if you were using the codebase of the equaliser prototype) - there was a problem with the user permissions of /home/mopidy/.alsaequalbin that I've since fixed.

On softvol: does setting mixer = software in Mopidy not already pretty much accomplish the same thing? It will then just do software-based mixing directly in Mopidy, instead of it going to ALSA for software mixing later on via softvol, if I understand it correctly.

@kingosticks
Copy link
Member

I was using a control file in /tmp with correct permissions so it wasn't
that.

Software mixer is Mopidy's volume. I wanted an alsa softvol to sit between
a virtual sound device (which everything on the system outputs to) and the
actual card. So it would control the volume of the entire system, not just
mopidy.
On 29 Jul 2015 10:56, "John Cass" notifications@github.com wrote:

The GStreamer error may have been my fault (if you were using the codebase
of the equaliser prototype) - there was a problem with the user permissions
of /home/mopidy/.alsaequalbin that I've since fixed.

On softvol: does setting mixer = software in Mopidy not already pretty
much accomplish the same thing? It will then just do software-based mixing
directly in Mopidy, instead of it going to ALSA for software mixing later
on via softvol, if I understand it correctly.


Reply to this email directly or view it on GitHub
#309 (comment)
.

@jcass77
Copy link
Member Author

jcass77 commented Jul 29, 2015

I managed to get softvol working after spending much too long on it.

But now it appears that it is only possible to activate one plugin at a time, and that softvol cannot be chained with equal.

If we can only have one, then I'd rather go with equal as we've got working volume management already.

I've pushed e2d038c which just reverts to using the VOLUME variable again, and sets the hardware volume to recommended settings for the HifiBerry DAC+ and amp+. This should at least ensure that these devices work out of the box without significant distortion when they are first plugged in.

I'm giving up on the rest.

@jcass77
Copy link
Member Author

jcass77 commented Dec 23, 2015

Just following up on this PR. I think it would make it easier for users to get the DAC+ and Amp+ up and running with good sound quality out of the box.

See: https://discuss.mopidy.com/t/volume-change-on-boot/971/2 and https://discuss.mopidy.com/t/volume-change-on-boot/971/4 - seems to be causing some frustration.

@jcass77 jcass77 mentioned this pull request Jan 7, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants