Sometimes the ALSA mixer can be modified during a point at shutdown
which causes a race condition trying to update the volume of an
unlinked sink.
Includes typo fix by our Chief Typo Spotter, Colin, and a clarifying
comment by me.
BugLink: http://bugs.launchpad.net/bugs/841968
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
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.
revents marked as POLLOUT|POLLERR|POLLWRNORM in "underrun" case that will
trigger unexpected log "ALSA woke us up to write new data to the device, but
there was acturally nothing to write...".
This patch avoids this log message.
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).
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 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)
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.
How about this? There are a couple of bugs in sink_write_volume_cb,
by the way. Another patch will be sent once this dB value printing
patch is accepted.
-- 8< --
Make new defines for the smoother window size and adjust time constants instead
of reusing some unrelated constant.
Increase the smoother window size even more because the bigger it is, the
better. Since we have a 200ms max update interval and the max smoother history
is 64 entries, 10seconds is a good default.
Decrease the smoother adjust time to 1 second. The previous value of 4 seconds
was too much to adapt quickly after a resume.
Use snd_pcm_avail_delay() in pa_alsa_safe_delay() so that we can check the delay
value against the avail value and patch it up when it looks invalid. Only do
this for capture.
Move the code to start the capture and the smoother closer together to improve
smoother accuracy.
Rework things to look more like the alsa sink where the device is started in
only one place.
This allows the name registry to mangle the names of auto-detected sinks and
sources to be unique, which makes it possible to load multiple identical sound
cards using module-udev-detect.
At least for now the module argument can only be passed through
module-alsa-card.
The smoother is paused when the device is suspended but never resumed on
unsuspend. Pass the paused = FALSE flag to the pa_smoother_reset() call to make
it unpause when unsuspending. This patch improves source timings quite a bit.
Positive base volume can happen, if the alsa volume range has been limited. For
example, in an embedded environment it may be known that the sound device is
capable of louder output than what the speakers can handle, so setting the max
volume below 0 dB makes sense.
In virtual machines sound card clocks and OS scheduling tend to become
unreliable, adding various 'uneven' latencies. The adaptive algorithm
that handles drop-outs does not handle it this well: in contrast to
drop-outs on real machines that are evenly distributed, small and can
easily be encountered via the adpative algorithms, drop-outs in VMs tend
to happen abruptly, and massively, which is not easy to counter.
This patch simply disables timer based scheduling in VMs reverting to
classic IO based scheduling. This should help make PA perform better in
VMs.
https://bugzilla.redhat.com/show_bug.cgi?id=532775
- As discussed on alsa-devel it's probably better to initialize the
buffer size first, followed by the period size. If that fails try the
other way round. If that fails try to configure only buffer size. If
that fails try to configure only period size. Finally, try to
configure neither.
- Don't require integral periods anymore.
Both of these changes should help improving compatibility with various
weirder sound devices, such as TV cards.
- drop the 'virtual_' prefix from s->virtual_volume since we don't
distuingish between reference and real volumes for sources
- introduce an accuracy for source volumes: if the hardware can control
the volume "close enough" don't necessarily adjust the rest in
software unless it is beyond a certain threshold. This should save a
little bit of CPU at the expensive of a bit of accuracy in volume
handling.
- other minor cleanups
