This is needed for building with anonymous unions. A bunch of calls to
fail() that used to mysteriously work need fixing -- fail() is a macro
that takes a printf-style message as an argument. Not passing this
somehow worked with the previous compiler flags, but breaks with
-std=c11.
The AGC code no longer seems to honour the analog volume limits we set,
and internally uses 0-255 as the volume range. So we switch to use that
(keeping the old API usage as is in case this gets fixed upstream).
This allows us to inherit the sample spec parameters from the sink and
source master (rather than forcing 32 kHz / mono). It is still possible
to override some of the parameters for the source side with modargs.
My original testing showed that these parameters provided a decent
perf/quality trade-off on lower end hardware (which I no longer have
access to). I figure it makes sense to continue with that for now, and
in the future this can be relaxed (use_master_format=yes could be the
default, and resource-constrained systems can disable it).
In the refactoring, I'm expressing the constraints in what I see to be a
more natural way -- rec_ss expresses what we're feeding the canceller,
so it makes sense to apply the constraints on what the canceller accepts
there. This then propagates to the output spec.
This also exposes the range of sample rates that the library actually
supports (8, 16, 32 and 48 kHz).
The original intention was to configure low enough parameters to keep
CPU consumption down. Prior to this change, we assumed that the EC
backend would override the sink parameters based on the source
parameters to achieve this goal, and with this change we remove that
assumption by forcing the default parameters for the sink to be low
enough.
It's not possible to enable the intelligibility enhancer at the
moment, because the feature would require modifying the audio that we
play to speakers, which we don't do currently. All audio processing is
done at the source side, and it's not easy to change that.
This patch is based on Arun Raghavan's code, I just reordered things
a bit and reworded the FIXME comment.
This creates a longer filter that is more complex and less sensitive to
incorrect delay reporting from the hardware. There is also a
delay-agnostic mode that can eventually be enabled if required.
In some very quick testing, not enabling this seems to provide better
results during double-talk.
In file included from pulse/timeval.c:32:0:
pulse/timeval.c: In function 'pa_timeval_add':
./pulsecore/macro.h:303:28: warning: left shift of negative value [-Wshift-negative-value]
? ~(~(type) 0 << (8*sizeof(type)-1))
reported by Ubuntu gcc-6
gcc-6 adds -Wshift-negative-value (enabled by -Wextra) which warns
about left shifting a negative value. Such shifts are undefined
because they depend on the representation of negative values.
also works with -Wshift-overflow=2
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
modules/module-stream-restore.c: In function 'clean_up_db':
modules/module-stream-restore.c:2344:74: warning: comparison of constant '0' with boolean expression is always true [-Wbool-compare]
pa_assert_se(entry_write(u, item->entry_name, item->entry, true) >= 0);
reported by Ubuntu gcc-6
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
Loading X stuff from default.pa is a bad idea, since it doesn't work
if there are multiple X sessions, or PulseAudio is started outside the
X session. Since it's a bad idea, don't encourage it by including
examples that do so.
I also removed the sample loading examples. I don't think the examples
are particularly useful, since nothing uses the loaded samples once
module-x11-bell is removed from the configuration.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=93109
Previously a missing key would cause this kind of log output:
D: [pulseaudio] module-device-manager.c: Database contains invalid data for key: sink:auto_null (probably pre-v1.0 data)
D: [pulseaudio] module-device-manager.c: Attempting to load legacy (pre-v1.0) data for key: sink:auto_null
D: [pulseaudio] module-device-manager.c: Size does not match.
D: [pulseaudio] module-device-manager.c: Unable to load legacy (pre-v1.0) data for key: sink:auto_null. Ignoring.
That is now replaced with
D: [pulseaudio] module-device-manager.c: Database contains no data for key: sink:auto_null
This gets rid of an error message from the debug log. If
volume_factor_source would actually be used somewhere, this bug would
have caused more severe problems.
volume_factor_source should have the source's channel map. When moving
the stream, the volume needs to be remapped from the old source's
channel map to the new source's map. However, when the stream is being
moved, there is a period where the old source has already been
forgotten and the new source isn't yet known, so the remapping can't
be done directly between the two channel maps. Instead, the volume is
remapped from the old source's map to the stream's own map when the
move starts, and again remapped from the stream's map to the new
source's map when the move finishes.
The first remapping was missing, causing the second remapping fail and
print an error to the log.
(I checked the sink input code as well. It didn't have this bug.)
Applying the volume after resampling means mismatch between the volume
channel map and the data channel map.
volume_factor_source is not currently used anywhere, so this bug
hasn't been causing any problems. I noticed it while reading the code.
This will likely be needed in the future when we start supporting high
bitrate passthrough, and there actually seem to be people 352/384 kHz
out there (potentially as an intermediate production step).
If 'pa_modargs_new' returns a NULL, we need to be careful to not call
'pa_modargs_free' in the failure path since it requires that we pass it
a non-null argument. Also updates 'module-bluetooth-policy.c:pa__init'
to follow the standard "goto fail" pattern used everywhere else.
Signed-off-by: Jason Gerecke <killertofu@gmail.com>
There is no way to check CPU type in a portable way across ABIs.
Assume if pointers are 64-bit that CPU is capable to perform fast
64-bit operations. Add an extra check to handle x32-ABI.
PulseAudio by default builds with -Wundef. If we add -Werror=undef this
missing define is fatal. By default build log is full of entries like:
In file included from ./pulsecore/core.h:47:0,
from ./pulsecore/module.h:31,
from ./pulsecore/sink-input.h:31,
from pulsecore/sound-file-stream.c:36:
./pulsecore/sample-util.h: In function 'pa_mult_s16_volume':
./pulsecore/sample-util.h:58:5: warning: "__WORDSIZE" is not defined [-Wundef]
#if __WORDSIZE == 64 || ((ULONG_MAX) > (UINT_MAX))
^
(NetBSD-7.99.21 with default GCC 4.8.5)
This change fixes build issues on NetBSD.
This also address a bug reported by Shawn Walker from Oracle (possibly Solaris):
Bug 90880 - builds can fail due to non-portable glibc-specific internal macro usage
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
The old code fetched the channel name via AudioObjectGetPropertyData()
and accessed the "returned" data as a plain char buffer.
This may or may not have worked at some point according to the Apple
CFString documentation, which warns that the actual data layout is an
implementation detail and subject to change at any time.
On recent OS X versions, this behavior led to "random data" channel
names like >H��{, H��{<.
We need to actually let AudioObjectGetPropertyData() populate a CFString
struct and convert this into a plain char buffer.
The conversion function will not free the CFString, so do that in the
caller.
Signed-off-by: Mihai Moldovan <ionic@ionic.de>
This isn't a great fix, but we need ALSA API to do this right. In the
mean time, USB devices work fine with timer-based scheduling, so there's
no reason to force a large minimum latency by disabling tsched on them.
