Now that subset mixer paths are removed, this workaround is no longer needed.
This effectively reverts 1c38b5d478 but due
to me forgetting to add files and adding a couple extra workarounds after,
it's easier to just do this manually rather than run git-revert.
In order to try and avoid 'spamming' the user with port choices,
attempt to detect and remove any pointless paths in a path set. That is
any paths which are subsets of other paths.
This should solve a problem case with some USB Headsets which result in
two paths both involving the 'Speaker' element. When no 'Master' element
exists (which is quite common on head/handsets), then the first path
(analog-output) will contain the 'Speaker' in a way that completely fits
with in the use of the 'Speaker' element in the other path
(analog-output-speaker).
Unification is really just a 'lowest common denominator' system. If any
paths do not support volume, mute or decibels, then mark them all as not
having them.
This was originally done this way because the flags set on sinks that
dictate if it supports h/w volume, mute etc. could not be changed after
the sink was created.
The fact that these flags could not change has now been change in the
previous commits, and thus there is now no need to use this 'lowest
common denominator' approach as we can fully support the various
different combinations, even if they change after initial creation
of the sinks/source.
Some sink flags are really just a product of what callbacks
are set on the device. We still enforce a degree of sanity
that the flags match the callbacks set, but we also set the
flags automatically in our callback setter functions to
help ensure that a) people use them and b) flags & callbacks
are kept in sync.
This is not currently useful but future commits will make further
changes concerning automatic setting of flags and event delivery
that makes this structure necessary.
This is a workaround - these usb headsets have one output volume
control only, labeled "Speaker". This causes the default profile
set to not control the volume at all, which is a bug. Workaround
that by creating a separate profile set.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
The previous logic in ade0a6f884
does not work with for input volumes.
This was discussed on the mailing list:
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2011-May/010091.html
This approach can introduce a problem when setting the volumes
for sources. What follows is Tanu Kaskinen's analysis:
[quote]
I'll quote the log:
D: protocol-native.c: Client pavucontrol changes volume of source alsa_input.pci-0000_00_1b.0.analog-stereo.
D: alsa-source.c: Requested volume: 0: 45% 1: 45%
D: alsa-source.c: in dB: 0: -20.71 dB 1: -20.71 dB
D: alsa-source.c: Got hardware volume: 0: 45% 1: 45%
D: alsa-source.c: in dB: 0: -21.00 dB 1: -21.00 dB
D: alsa-source.c: Calculated software volume: 0: 101% 1: 101% (accurate-enough=no)
D: alsa-source.c: in dB: 0: 0.29 dB 1: 0.29 dB
D: source.c: Volume going up to 29273 at 270475970821
D: source.c: Volume change to 29273 at 270475970821 was written 34 usec late
D: alsa-source.c: Written HW volume did not match with the request: 0: 45% 1: 45% (request) != 0: 42% 1: 42%
D: alsa-source.c: in dB: 0: -21.00 dB 1: -21.00 dB (request) != 0: -22.50 dB 1: -22.50 dB
Looking at the last line, the requested volume seems to hit exactly the
right step (-21.00dB), but for some reason Alsa decides to choose
something else. I'm pretty sure that this happens because of rounding
errors. In the first phase we ask Alsa what dB value we should set, and
it returns -21.00 dB. The value is given as a long int, but we convert
that to pa_cvolume. Then when we set the volume, we convert the
pa_cvolume value back to a long integer. At this point I believe it gets
converted to -2101. This is not visible in the debug message for some
reason - the rounding algorithm must be different from what was used
with the pa_cvolume -> long conversion.
[/quote]
The commit after this contains a patch that addresses this issue.
This piggy backs onto the previous changes for protocol 22 and
thus does not bump the version. This and the previous commits should be
seen as mostly atomic. Apologies for any bisecting issues this causes
(although I would expect these to be minimal)
Add a variable to track whether the actual volume is set or not.
Suppose this:
min volume: -126 max volume: 0
then when user wants to set some constant volume to -10, it would fail.
While the alsa values are typically positive, some values are "funky"
and have negative values. It is desirable to fix this at the alsa
level so that the numbers are positive, but it's not technically
invalid, and thus we have to support it.
Discussed here:
http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/9832
and
http://thread.gmane.org/gmane.linux.alsa.devel/85459
Since we currently have two mechanisms to signal a passthrough
connection (non-PCM format or PA_SINK_INPUT_PASSTHROUGH flag), we move
all the related checks into functions and use those everywhere.
This makes things more consistent, and should we decide to get rid of
the flag, we only need to change pa_sink_input_*_is_passthrough()
accordingly.
When a passthrough sink-input is added, we need to reconfigure the
sink's sample rate since no resampling occurs. We revert to the original
rate when the passthrough sink-input is removed.
This removes the passthrough flag from sinks since we will drop
exclusively passthrough sinks in favour of providing a list of formats
supported by each sink. We can still determine whether a sink is in
passthrough mode by checking if any non-PCM streams are attached to it.
The check is inspired by a driver that returned higher dB limit from
snd_mixer_selem_get_playback_dB_range() than what _ask_playback_vol_dB()
returned at maximum integer volume.
On 64-bit systems LONG_MAX is greater than the largest possible value of a
uint32_t variable, which caused the compiler to warn about a comparison that is
always false. On 32-bit systems pa_atou() can return a value that will overflow
when assigned to e->volume_limit, which has type long, so the comparison was
necessary.
This dilemma is resolved by using pa_atol() instead of pa_atou().
This change makes it possible to configure an arbitrary constant volume for a
volume element in the path configuration, which is applied when the path is
selected. Note: this is only useful when the exact hardware and driver are
known beforehand.
pulsecore/core-util.c: In function ‘pa_hexstr’:
pulsecore/core-util.c:1858: warning: cannot optimize loop, the loop counter may overflow [-Wunsafe-loop-optimizations]
modules/alsa/alsa-mixer.c: In function ‘pa_alsa_decibel_fix_dump’:
modules/alsa/alsa-mixer.c:3678: warning: cannot optimize possibly infinite loops [-Wunsafe-loop-optimizations]
modules/alsa/alsa-mixer.c: In function ‘pa_alsa_path_set_new’:
modules/alsa/alsa-mixer.c:2640: warning: cannot optimize loop, the loop counter may overflow [-Wunsafe-loop-optimizations]
Without this, p->max_dB could never be less than 0 dB, because the loop at the
end of pa_alsa_path_probe() would reset p->max_dB to 0 as soon as the loop
encountered a channel that wasn't touched by any element.
There was a similar issue for p->min_dB too (it could never be more than 0 dB),
which is also fixed by this patch.
This feature is mainly useful in embedded systems that have built-in speakers.
In such situations the full audio path is known beforehand, so it's possible to
know what is the maximum sensible volume, and any higher volume can be
disabled.
The volume limit is set in path configuration files in the [Element] section,
using option "volume-limit". The value is the desired maximum volume step of
the volume element.
It seems git managed to mess up a git-am with a patch from
David which moved where this function was called element_probe
to within itself (recursive which could normally lead to an
infinite loop, but as it was now never called from anywhere else,
this didn't happen).
Thank you to Maarten for spotting and following up the issue.
Make sure that mic and line (with common names) use the specific
path instead of the analog-input one.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Now you can add required-any to elements in a path and the path
will be valid as long as at least one of the elements are present.
Also you can have required, required-any and required-absent in
element options, causing a path to be unsupported if an option is
(not) present (simplified example: to skip line in path if
"Capture source" doesn't have a "Line In" option).
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Add front mic, rear mic, and docking line-in. These are likely to be
present on modern hda chips, for reference see
linux-2.6/sound/pci/hda/hda_codec.c:hda_get_input_pin_label
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
