Volume percentages are inconsistent with other applications (ncmpcpp, pavucontrol)
JakeStanger opened this issue · comments
I've been shamelessly stealing referencing your PA code for my own project and I've come across a bug in the way it's displaying volumes currently.
Using the libpulse LinearVolume seems to result in some weird not-actually-percentage value. I assume it's something to do with the log scale, and it's supposed to be linear to human hearing.
The issue with that is that just about every other volume program calculates the percentage differently, causing Mixxc to show very different values. For example, I'm using ncmpcpp for music and that allows controlling the sink input volume directly, and is always out of alignment. pavucontrol seems to agree with ncmpcpp and not Mixxc.
I have found another Rust mixer project which has a couple of helper methods for calculating to/from a percentage which seem to line up with the other mixers. I believe you could grab these and stick them in to correct this:
https://github.com/jantap/rsmixer/blob/a35039adaaf9dcf5e27d939df58d83335f76dea3/src/util.rs#L3-L25
I've not managed to get anywhere with a PA client before now and I've been searching months for an example, so this has been a lifesaver. I hugely appreciate the amount of work put into creating this and I will definitely give the project a shout-out.
I think i was aware of this at some point of development. Being in sync with other applications that show volume was never a point for me and it might be impossible in some cases (check out how YouTube treats volume on different videos.....). I personally don't like touching volume controls in applications, because they sometimes don't even sync with audio server's volume slider and tend to remember their own stuff and I tend to forget that I touched something and it's this whole mess of forgotten settings, i think you get my point.
Currently at 2% in Mixxc's I can barely hear anything (as i expect), but at the same time pavucontrol displays like 30% at that point and anything that's <20% I would never even set, because I just can't (distinctively) hear there. Of course my custom EQ with bass enhancer in Easyeffects and inexpensive Sennheisers without amp don't help the experiment much, but for me personally Mixxc's percentages make more sense.
Thanks for your interest and I'm glad that you found this project useful for your own cool thing.
I'll leave this issue opened, but as i understand you're not interested in using this Mixxc by itself.
If you or someone else actually needs a compile flag or CLI flag to make Mixxc's behavior more consistent with pavucontrol or other solutions they can come here and ask or propose a PR. It should be easy to solve.
I think that's fair enough. I can see why Pulse gives volumes in the way it does, and it does almost seem strange that the standard seems to be different. It sounds like our workflows do differ slightly around this, which might be why we prefer it the other ways around.
I'm not currently looking to use this, but that doesn't mean I won't be in future. If I do, I'll definitely open a PR (assuming nobody beats me to it). My personal take would be that a CLI flag (something like --non-linear or --logarithmic) could be used to switch the percentage algorithm.
I got a chance to revisit this while making implementation for the master slider that controls sink volume.
From my understanding, I'm doing almost* everything correctly.
https://docs.rs/libpulse-binding/latest/libpulse_binding/volume/index.html
The Volume in PulseAudio are cubic in nature and applications should not perform calculations with them directly. Instead, they should be converted to and from either dB or a linear scale.
This explains why i can barely hear <30% mentioned by me in pavucontrol. Because raw values for software volume are cubic, and linear for sinks and sources.
Don’t use the above functions on sink and source volumes, unless the sink or source in question has the DECIBEL_VOLUME or DECIBEL_VOLUME flag set.
Where "above functions" refers to Volume::multiply() ChannelVolumes::sw_multiply() and conversions through VolumeDB VolumeLinear. (that's how I read it)
b0815ce makes it Ctrl-C Ctrl-V level of simple to change if someone really really needs it. I'm not a fun of doing things the wrong way to be compatible with stuff that does things the wrong way and since there's not much of an interest here, I'm gonna close this issue.
Feel free to reopen if you think that I misunderstand something.