This consumes less power, has low (no?) perceivable difference, and
allows the default configuration to work out of the box on low-end
systems (such as netbooks).
This reverts commit a9c3f2fb0f.
It has been recently agreed that ports should somehow have some physical
meaning, leading to the port merge in module-bluetooth-device.
With this assumption in mind, it is very unlikely that a card would
add or remove ports dynamically. Therefore, the core can be simplified
by removing the support for this.
The revert affects the code added to module-card-restore in commit
a1a0ad1af2, which can now be partially
removed.
Conflicts:
src/pulsecore/card.c
src/pulsecore/core.h
If minreq is not explicitly specified, it was always initialized to
20 ms (DEFAULT_PROCESS_MSEC). However when the total latency is not
much higher than 20 ms, this is way too high. Instead use
tlength/4 as a measure: this will give a decent sink_usec in all
modes (both traditional, adjust latency and early request modes).
This greatly improves PulseAudio's ability to ask for data in time
in low-latency scenarios.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Tlength should never be set higher than maxlength. While this is
corrected by memblockq later, we still need a correct tlength for
the subsequent calculations.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
This reverts commit 6733caf114.
Apparently, the EOF bit gets set only after there has been an attempt
to read more data than the file contains, so just reading the last
byte isn't sufficient.
fgets() returns NULL in case there's an error or f is at EOF. The
while condition just checked that f is not at EOF, therefore an error
must have happened.
Previously, a drain request was acknowledged up to two hw buffers
too late, causing unnecessary delays.
This implements a new chain of events called process_underrun
which triggers exactly when the sink input has finished playing,
so the drain can be acknowledged quicker.
It could later be improved to give better underrun reporting to
clients too.
Tested-by: Dmitri Paduchikh <dpaduchikh@gmail.com>
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Some cards are capable to announce if a specific profile is available or
not, effectively predicting whether a profile switch would fail or would
likely succeed. This can for example be useful for a UI that would gray
out any unavailable profile.
In addition, this information can be useful for internal modules
implementing automatic profile-switching policies, such as
module-switch-on-port-available or module-bluetooth-policy.
In particular, this information is essential when a port is associated
to multiple card profiles and therefore the port availability flag does
not provide enough information. The port "bluetooth-output" falls into
this category, for example, since it doesn't distinguish HSP/HFP from
A2DP.
Generalize the availability flag in order to be used beyond the scope of
ports.
However, pa_port_availability_t is left unchanged to avoid modifying the
protocol and the client API. This should be replaced by pa_available_t
after a validation phase of this new generic enum type.
Unloading modules in the reverse order is the "more logical" thing
to do, and speeds up shutdown somewhat, e g by not loading
module-null-sink at shutdown.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
The previous patch removed module-gconf's dependency on the userdata
pointer of the free callback, and that was the only place where the
userdata pointer of pa_free2_cb_t was used, so now there's no need for
pa_free2_cb_t in pa_hashmap_free(). Using pa_free_cb_t instead allows
removing a significant amount of repetitive code.
similar to volume functions, simplifies leftover samples handling
for SIMD'd code path
use concrete pointer type (e.g. int16_t*) instead of void*,
saves several casts
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
move code to function pa_mult_s16_volume() in sample-util.h
use 64 bit integers on 64 bit platforms (it's faster)
on i5, 2.5GHz (64-bit)
Running suite(s): Mult-s16
32 bit mult: 1272300 usec (avg: 12723, min = 12533, max = 18749, stddev = 620.48).
64 bit mult: 852241 usec (avg: 8522.41, min = 8420, max = 9148, stddev = 109.388).
100%: Checks: 1, Failures: 0, Errors: 0
on Pentium D, 3.4GHz (32-bit)
Running suite(s): Mult-s16
32 bit mult: 2228504 usec (avg: 22285, min = 18775, max = 29648, stddev = 3865.59).
64 bit mult: 5546861 usec (avg: 55468.6, min = 55028, max = 64924, stddev = 978.981).
100%: Checks: 1, Failures: 0, Errors: 0
on TI DM3730, Cortex-A8, 800MHz (32-bit)
Running suite(s): Mult-s16
32 bit mult: 23708900 usec (avg: 237089, min = 191864, max = 557312, stddev = 77503.6).
64 bit mult: 22190039 usec (avg: 221900, min = 177978, max = 480469, stddev = 68520.5).
100%: Checks: 1, Failures: 0, Errors: 0
there is a test program called mult-s16-test which checks that the functions compute the
same results, and compares runtime
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
have individual function for mixing stream with different sample format instead
of huge case block in pa_mix()
shorter functions, prepare for optimized code path
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
idea is to allow optimized code path (similar to volume code)
and rework/specialize mixing cases to enable runtime performance improvements
no functionality changes in this patch
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
The patch intends to reduce computational load when resampling AND remapping. The PA
resampler performs the following steps:
sample format conversion -> remapping -> resampling -> sample format conversion
In case the number of output channels is higher than the number of input channels, the
resampler has to be run more often than necessary. E.g. in case of mono to 4-channel remapping,
the resampler runs on 4 channels separately.
To ímprove this, the PA resampler pipeline is made adaptive:
if out-channels <= in-channels:
sample format conversion -> remapping -> resampling -> sample format conversion
if out-channels > in-channels:
sample format conversion -> resampling -> remapping -> sample format conversion
Signed-off-by: Peter Meerwald <p.meerwald@bct-electronic.com>
Remixing one channel map to another is (except for special cases) done
via a linear mapping between channels, whose corresponding matrix is
computed by calc_map_table(). The k-th row in this matrix corresponds to
the coefficients of the linear combination of the input channels that
result in the k-th output channel. In order to avoid clipping of samples
we require that the sum of these coefficients is (at most) 1. This
commit ensures this.
Prior to this commit tests/remix-test.c gives 52 of 132 matrices that
violate this property. For example:
'front-left,front-right,front-center,lfe' -> 'front-left,front-right'
prior this commit after this commit
I00 I01 I02 I03 I00 I01 I02 I03
+------------------------ +------------------------
O00 | 0.750 0.000 0.375 0.375 O00 | 0.533 0.000 0.267 0.200
O01 | 0.000 0.750 0.375 0.375 O01 | 0.000 0.533 0.267 0.200
Building the matrix is done in several steps. However, only insufficient
measures are taken in order to preserve a row-sum of 1.0 (or leaves it
at 0.0) after each step. The current patch adds a post-processing step
in order check for each row whether the sum exceeds 1.0 and, if
necessary, normalizes this row. This allows for further simplifactions:
- The insufficient normalizations after some steps are removed. Gains
are adapted to (partially) resemble the old matrices.
- Handling unconnected input channls becomes a lot simpler.
- Separate the cases with PA_RESAMPLER_NO_REMAP or PA_RESAMPLER_NO_REMIX
set and remove redundant if-conditions.
- Fix C90 compiler warning due to mixing code and variable declaration.
- Do not repeatedly count number of left, right and center channels in
the input channel map.
The logic of calc_map_table() remains unaltered.
Earlier, -1 was returned if the memchunk size was not a multiple of the frame
size. Now, it is verified unconditionally through an assertion. Error code -1
is still returned when the memblock queue is full.
In those few cases where the return value of pa_memblockq_push() is checked,
an overflow is assumed to be the reason in case an error code is returned.
use (1<<15) instead of 0x7fff as a factor when converting from s16 to float32
use (1<<31) instead of 0x7fffffff as a factor when converting from s32 to float32
the change is motivated by the following desireable properties:
* s16_from_f32(f32_from_s16(x)) == x for all possible s16 values
* x / (1.0f << 15) == x * (1.0f / (1 << 15)) for all x in s16
above changes enable easier optimization while guaranteeing bit-exact results
further, other audio sample conversion code (libavresample) does it the same way
v3 (comments Tanu):
* fix saturation in pa_sconv_s16le_from_f32ne_neon(), use vqrshrn
v2 (comments Tanu):
* fix comments in ARM NEON code
* use llrintf() in pa_sconv_s32le_from_float32ne()
Signed-off-by: Peter Meerwald <p.meerwald@bct-electronic.com>
Cc: Tanu Kaskinen <tanuk@iki.fi>
Problem: s16 to s32 conversion is performed as s16->float->s32 (via work
format float) for resamplers TRIVIAL, COPY, PEAKS.
Precision and efficiency suffers: e.g. 0x9fff results in 0x9ffe4001 (instead
of 0x9fff0000) and there are two sample format conversions instead of one
conversion.
Solution: If input or output format is s16, then choose the work format
to be s16 as well.
If remapping is to be performed, we could stick to work format float32ne for
precision reseans. This is debateable.
Signed-off-by: Peter Meerwald <p.meerwald@bct-electronic.com>
