Changes:
- Mention that source outputs have volume too.
- Don't claim that most distributions have flat volumes enabled.
- Volumes use a cubic scale, not logarithmic.
- Reword the warning about using the conversion functions on hardware
volumes. The old wording gave the incorrect impression that hardware
volumes could never be converted to dB or linear scale.
The gnome/unity-control-center UIs have a master volume slider, and
three sub-sliders: balance, fade, and subwoofer. Balance and fade
use PA's set_balance and set_fade APIs accordingly, but the subwoofer
slider sometimes does unintuitive things.
In order to make that slider behave better, let's add a LFE balance
API that these volume control UIs can use instead. With this API,
the UI can balance between "no subwoofer" and "only subwoofer" with
"equal balance" in the middle, which would make it more consistent
with the behaviour of the other sliders.
BugLink: https://bugzilla.gnome.org/show_bug.cgi?id=753847
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
FSF addresses used in PA sources are no longer valid and rpmlint
generates numerous warnings during packaging because of this.
This patch changes all FSF addresses to FSF web page according to
the GPL how-to: https://www.gnu.org/licenses/gpl-howto.en.html
Done automatically by sed-ing through sources.
Hello.
Over time, I became aware of several instances of tempting but
semantically incorrect usage of PulseAudio API (one from my own bad
proposal of "improving" Wine, one from Parole media player and one
from Webkit-GTK). I want to document these gotchas so that other
developers don't fall for that. See the attached patch.
I have checked that the rendered HTML is correct, but need someone to
confirm the factual accuracy of the proposed changes and, possibly, to
improve the wording.
--
Alexander E. Patrakov
same for e.g. versus e.g.\ and e.g. versus E.g.
this is ueber-nitpicking: will anybody ever notice?
Signed-off-by: Peter Meerwald <p.meerwald@bct-electronic.com>
This value is not a technical upper limit, it's just a 'sensible'
value that is not crazy high, but also allows software amplification
above 0dB (aka 100%) for very quiet audio sources.
We recommend that a comprehensive volume control UI should allow
users to set volumes up to this limit, although of course should
deal gracefully if the user has set the volume even higher than this
without resulting in a feedback loop that effectively limits the
upper volume.
The value chosen is +11dB. This was selected somewhat subjectively
and is very similar to the current 150% that gnome-volume-control
uses (which is ~+10.57dB).
On the plus side, we now recommend that everyone allows
'Volumes up to 11' which is pretty awesome.
http://en.wikipedia.org/wiki/Up_to_elevenhttps://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-April/006945.htmlhttps://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-April/006950.html
Due to how our branching worked out, these new features will
debut in v1.0 and not v0.9.22 which has already been released
from the stable-queue branch
This decrease PA_VOLUME_MAX to be less than 2^31. We want to do this in
order to simplify signed arithmetic when applying software volume
scaling (since the volume can now always be safely treated as a signed
number).
This ensures that we always clamp the volume to PA_VOLUME_MAX. While
this currently has no effect, it will be required for making sure we
don't exceed PA_VOLUME_MAX when its value changes in the future.
This adds a PA_VOLUME_IS_VALID() macro for checking if a given
pa_volume_t is valid. This makes changes to the volume ranges simpler
(just change PA_VOLUME_MAX, for example, without needing to modify any
other code).
A good many of the header files are broken into a function
reference page and an overview page. These changes add
a direct link from each function reference page to their
overview page if one exists.
Mostly change "Set the volume of all channels" to
"Set the volume of the first n channels" as the first is incorrect,
it doesn't set all the channels and doesn't explain what n was for.
Note also the willneed/will_need inconsistency. I guess it could be nice to ASAP
choose one of them and introduce a backward compatibility hack for the other.
The issues was mostly found with:
for a in $(grep -r '^[ /]\*.*()' $(
find -name '*.[ch]') |
sed 's,^.* \([^ ]*\)().*$,\1,g' |
sort |
uniq |
grep ^pa_)
do
grep -rq "^.[^*].*\<$a(" $(find * -name '*.h') || echo $a
done
added function to increase volume not exceeding specified limit
simply changed PA_VOLUME_MAX to 'limit' in pa_cvolume_inc
pa_cvolume_inc now calls pa_cvolume_inc_clamp with PA_VOLUME_MAX limit
