Hi. Could you please apply the attached trivial patch so that I could drop
the corresponding instructions from dcaenc's README file in the future? It
adds a profile for on-the-fly DTS encoding, similar to the existing AC3
profile.
--
Alexander E. Patrakov
>From 22310a1c28385acc7ce883e020b9eb2e5b0813b7 Mon Sep 17 00:00:00 2001
From: "Alexander E. Patrakov" <patrakov@gmail.com>
Date: Sun, 12 Feb 2012 17:19:48 +0600
Subject: [PATCH] alsa: add DTS profile
This requires dcaenc from http://aepatrakov.narod.ru/dcaenc/
If alsa settings/options were used, the string to construct the
name was freed, leading to dangling pointers to strings inside
the hashmap.
BugLink: https://bugs.launchpad.net/bugs/932804
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
The practical problem is that some users were left with only one
"LFE on Mono" port, as analog-output was considered a subset of
analog-output-lfe-on-mono. Which was not what they wanted.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=40910
BugLink: https://bugs.launchpad.net/bugs/922656
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
* If we don't have "Digital Speakers", we should say "Speakers"
instead of "Analog Speakers", and similar for other ports.
* Change "IEC958" to "S/PDIF" (more well known name)
* Add new ports and mappings for HDMI
* Change "Internal" to "Built-in" for the card name
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
* If mapping_probe_paths() fails to open the mixer, all paths are now
removed from the mapping's path sets.
* pa_path_set.probed isn't really used for anything (removed).
* If profile probing is configured to be skipped, mapping_paths_probe()
should still be called.
Thanks to Tanu for spotting.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
To be able to add ports to all profiles, we need to probe all
profiles at startup. To speed this up, we now have a cache of
probes paths which is owned by the profile set. Since paths
are now owned by the profile set, the path set must now have
a hashmap of paths instead of a linked list.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
The recommended way of setting available status is to call
pa_device_port_set_available, which will send a subscription event
to the relevant card. It will also fire a hook.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
The new module argument can be used to provide a custom
directory for loading alsa path configuration files. This is
useful for testing: no need to be root to create test
configuration files.
Instead of relying on the snd_mixer_* functions failing, we check for
POLLERR and POLLNVAL first. After this, any errors in handling the mixer
events are deemed fatal (that is we cause the ALSA source/sink thread to
terminate).
The case where POLLERR is set but POLLNVAL is not does not actually
occur, but we're making this a soft failure (stop polling the mixer, but
don't kill the I/O thread). If other conditions where POLLERR occurs
turn up, we need to handle them explicitly.
Thanks to Linus Torvalds for helping get this right.
This improves the error handling in the mixer rtpoll callback. It avoids
a crash if an error occurs (the rtpoll_item is freed but still
referenced), and specifically makes sure we don't continue trying to
poll the device if the card is disconnected.
This just covers Lennart's concern over the terminology used.
The majority of this change is simply the following command:
grep -rli sync[-_]volume . | xargs sed -i 's/sync_volume/deferred_volume/g;s/PA_SINK_SYNC_VOLUME/PA_SINK_DEFERRED_VOLUME/g;s/PA_SOURCE_SYNC_VOLUME/PA_SOURCE_DEFERRED_VOLUME/g;s/sync-volume/deferred-volume/g'
Some minor tweaks were added on top to tidy up formatting and
a couple of phrases were clarified too.
As reported in http://kpaste.net/04f1f3f
it is possible to call enumeration_is_subset with null pointers.
Handle that case instead of crashing. (It is also possible that
Tanuk's pending element_is_subset patch solves the issue, but this
nevertheless gives some extra security.)
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
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.
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.
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
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.
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>
When creating synthesized paths, pa_alsa_path_set_new() created duplicate
elements for each path, and one of the duplicate elements would be marked as
required absent. That made path probing fail. While debugging this, I noticed
also that pa_alsa_path_synthesize() didn't initialize p->last_element properly.
