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.
If the virtual sink is moved to a new master right after it has been created,
then the virtual sink input's memblockq can be rewound to a negative read
index. The data written prior to the move starts from index zero, so after the
rewind there's a bit of silence. If the memblockq doesn't have a silence
memchunk set, then pa_memblockq_peek() will return zero in such case, and the
returned memchunk's memblock pointer will be NULL.
That scenario wasn't taken into account in the implementation of
sink_input_pop_cb. Setting a silence memchunk for the memblockq solves this
problem, because pa_memblock_peek() will now return a valid memblock if the
read index happens to point to a hole in the memblockq.
I believe this isn't the best possible solution, though. It doesn't really make
sense to rewind the sink input's memblockq beyond index 0 in the first place,
because now when the stream starts to play to the new master sink, there's some
unnecessary silence before the actual data starts. This is a small problem,
though, and I don't grok the rewinding system well enough to know how to fix
this issue properly.
I went through all files that call pa_memblockq_peek() to see if there are more
similar bugs. play-memblockq.c was the only one that looked to me like it might
be broken in the same way. I didn't try reproducing the bug with
play-memblockq.c, though, so I just added a FIXME comment there.
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>
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.
There are two known cases where read-only or non-existing sink input volume is
relevant: passthrough streams and the planned volume sharing logic.
Passthrough streams don't have volume at all, and the volume sharing logic
requires read-only sink input volume. This commit is primarily working towards
the volume sharing feature, but support for non-existing sink input volume is
also added, because it is so closely related to read-only volume.
Some unrelated refactoring in iface-stream.c creeped into this commit too (new
function: stream_to_string()).
This change doesn't add any functionality in itself, but it will be useful in
the future for operating on chains of sinks or sources that are piggy-backing
on each other.
For example, the PA_PROP_DEVICE_MASTER_DEVICE property could
be handled in the core so that each virtual device doesn't have to maintain it
separately. By using the origin_sink and destination_source pointers the core
is able to see at stream creation time that the stream is created by a virtual
device, and then update that device's property list using the name of the
master device that the stream is being connected to. The same thing can be done
also when the stream is being moved from a device to another, in which case the
_MASTER_DEVICE property needs updating.
The check whether POSIX socket.h or WIN32 winsock2.h must be included can be
made centrally. The downside is that some functionality of e.g. arpa/inet.h is
also implemented in winsock.h, so that some files that don't use socket
functions, but do use inet.h functions, must also include pulsecore/socket.h.
(as well as arpa/inet.h)
Instead <pulsecore/poll.h> should be included. That file includes poll.h on
platform where it is appropriate. Also remove some unnecessary <ioctl.h>
includes.
This patch reflects a new capability that Lennart was wishing
for. Wish granted...
Re-submitting it now that alsa-lib 1.0.24
provides additional entry points to disable period
wakeups in timer-scheduling mode if hardware can
work without it (HDAudio, oxygen and Intel SST).
Example with standard playback on HDAudio output
Before change:
Top causes for wakeups:
3.8% ( 5.4) [hda_intel] <interrupt>
2.8% ( 4.0) alsa-sink
After change:
Top causes for wakeups:
2.3% ( 3.0) alsa-sink
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@intel.com>
This greatly simplifies the Orc-related make rules. The old system of
distributing generated files is gone, which means that anyone who wants
to build with Orc support enabled needs to have the orcc compiler
installed (presumably the orc 'devel' package in most distros).
When logging a suppression message do so on the same log level as the
suppressed messages.
Cherry picked by Colin Guthrie from ec5a785712
with a couple of additional changes due to extra limiting in master
that was not present in stable-queue.
The same logic is applied to the sample rate adjustments in module-rtp-recv,
module-loopback and module-combine:
- Each time an adjustment is made, the new rate can differ at most 2‰ from the
old rate. Such a step is equal to 3.5 cents (a cent is 1/100th of a
semitone) and as 5 cents is generally considered the smallest observable
difference in pitch, this results in inaudible adjustments.
- The sample rate of the stream can only differ from the rate of the
corresponding sink by 25%. As these adjustments are meant to account for
very small clock drifts, any large deviation from the base rate suggests
something is seriously wrong.
- If the calculated rate is within 20Hz of the base rate, set it to the base
rate. This saves CPU because no resampling is necessary.
