With some optimised sconv implementations (read NEON), rounding
inaccuracy might lead to a difference of 1 with the reference
implementation. The inaccuracy is worth the performance gain.
Also increases floating-point accuracy while printing errors to make
errors easier to analyse.
Rounding with 0.5 causes us to always round up for any value of the form
x.5. IEEE754 specifies round-to-nearest-even as the behaviour in this
case. This might not always be possible with NEON code, but this change
gets us much closer to it.
final:
* includes some minor style fixes and build-time changes to allow
building a single binary for neon and non-neon systems
v4:
* fix for sample length < 4
v3:
* convert from intrinsics to inline assembly
v2:
* load and store data with vld1/vld1q and vst1/vst1q, resp., to work
around alignment issues of compiler-generated vldmia instruction
* remove redundant check for NEON flags
Ubuntu/Linaro gcc 4.6.3
arm-linux-gnueabi-gcc -O2 -mcpu=cortex-a8 -mfloat-abi=softfp -mfpu=neon
runtime on beagle-xm:
D: [pulseaudio] sconv_neon.c: checking NEON sconv_s16le_from_float
I: [pulseaudio] sconv_neon.c: NEON: 3754 usec.
I: [pulseaudio] sconv_neon.c: ref: 58594 usec.
D: [pulseaudio] sconv_neon.c: checking NEON sconv_s16le_to_float
I: [pulseaudio] sconv_neon.c: NEON: 1831 usec.
I: [pulseaudio] sconv_neon.c: ref: 10528 usec.
I: [pulseaudio] sconv_neon.c: Initialising ARM NEON optimized conversions.
conversion may be off by one for some samples due to rounding issues
Commit dd31d652a ("utils: Adding a function to get volume from string")
uses pa_sw_volume_from_dB(), which is part of libpulse, in libpulsecore.
This breaks as-needed builds. We fix this by also building the volume
code in libpulsecommon.
UUIDs might be announced at any time, so a hook is needed to notify any
interested module. In practice, the UUIDs are quite stable with the
exception of the pairing procedure, where the UUIDs are reported by
BlueZ as soon as they are discovered.
This allows us to test the sconv code with the incoming samples at
various byte alignments. The test is also now split into correctness and
performance checks.
The IDT/Sigmatel codec driver often creates a "Mic Jack Mode" for
every mic jack, so it can change functionality between Mic and Line In.
However, as the "Mic Jack" is the standard naming, our current solution
does not make the Line In port unavailable when nothing is plugged in.
This patch makes the "Line In" port not to be created just because there
is a "Mic Jack Mode" that could be set to "Line". This makes the behaviour
consistent with e g "Dock Mic Jack Mode", "Front Mic Jack Mode" etc, where
we don't create a "Dock Line" or "Dock Mic" port either.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
modules/rtp/module-rtp-recv.c:462:8: warning: 'r' may be used uninitialized in this function [-Wuninitialized]
Signed-off-by: Peter Meerwald <p.meerwald@bct-electronic.com>
This factors out the basic measurement code for each test into a
separate block so that each test can be broken down into a basic
correctness test, and a performance comparison with minimum effort.
Am 23.10.2012 08:25, schrieb Arun Raghavan:
> On Tue, 2012-08-21 at 13:32 +0200, Thomas Martitz wrote:
>> Am 21.08.2012 08:51, schrieb Rémi Denis-Courmont:
>>> Le mardi 21 août 2012 00:50:34 Thomas Martitz, vous avez écrit :
>>>> There are tons of warnings, most of them because the function is not
>>>> recognized as printf-like.
>>> Removing checks looks very fishy.
>>>
>>> To use C99 and/or GNU format specifiers on MingW, you need to use the
>>> gnuprintf attribute instead of printf. With printf, the format string is
>>> validated according to the antiquated MSVC rules.
>>>
>> Interesting, I didn't know about gnuprintf. FWIW, what are those
>> antiquated MSVC rules? I assumed the return value which isn't int for
>> some affected functions?
> Is this one going to be respun?
>
Yes, here you go.
>From c5f15eec69bf95c9a1261e0d82abbd039156e75e Mon Sep 17 00:00:00 2001
From: Thomas Martitz <kuge@rockbox.org>
Date: Wed, 8 Aug 2012 17:38:04 +0200
Subject: [PATCH 1/3] gccmacro: Work around warnings due to printf redirection
by libintl.
Libintl defines printf as libintl_printf, which breaks the format
attribue. Unfortunately the workaround around provided by libintl
is only enabled for cygwin, but not for mingw builds. Therefore
install the workaround manually.
CXX libwebrtc_util_la-webrtc.lo
modules/echo-cancel/webrtc.cc: In function 'pa_bool_t pa_webrtc_ec_init(pa_core*, pa_echo_canceller*, pa_sample_spec*, pa_channel_map*, pa_sample_spec*, pa_channel_map*, uint32_t*, const char*)':
modules/echo-cancel/webrtc.cc:196:9: warning: 'rm' may be used uninitialized in this function [-Wuninitialized]
Signed-off-by: Peter Meerwald <p.meerwald@bct-electronic.com>
CC libpulsecore_2.98_la-svolume_arm.lo
pulsecore/svolume_arm.c: In function 'pa_volume_s16ne_arm':
pulsecore/svolume_arm.c:50:8: warning: assignment discards 'const' qualifier from pointer target type [enabled by default]
Signed-off-by: Peter Meerwald <p.meerwald@bct-electronic.com>
On Windows, strerror can actually return "Unknown Error"
(e.g. for large errnums). The code assumes the return value to be helpful.
Make it slightly more helpful by catching the message and appending the
errnum.
Calling pa_read() and pa_write() seems more appropriate since they deal better
with platform specific issues. This doesn't actually fix any open issue since
only stdio is affected but it seems more future proof.
On Windows, fdsem.c:flush() fails because sockets are set to non-blocking
mode, since pa_read() returns -1 (and errno == EWOULDBLOCK). I guess pa_read()
is expected to block in this case so make it actually block by calling poll().
Without this reading from stdin will eventually end with EOF (if there happens
to be a newline sign in the stream), because read() returns 0.
This patch fixes raw data input and piping to pacat on Windows.
Instead of repeatedly asking the discovery API to find a device given
our device path, let's hold a pointer to the device and make sure we
remove the reference when the hook is fired reporting that the device
has been removed. This makes the code easier to follow and slightly
more efficient.
The internal API in bluetooth-util should not use the const qualifier
for operations involving a device object. After all, the structure
contains many pointers and thus the const qualifier provides no real
protection.
Sometimes the kernel does not schedule us in due time, thus causing
an underrun. Adding a detection and a debug message will be a helpful
step in determining the cause of an underrun.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
CC pulseaudio-dumpmodules.o
daemon/dumpmodules.c:93:27: warning: redundant redeclaration of ‘lt__PROGRAM__LTX_preloaded_symbols’ [-Wredundant-decls]
/usr/include/ltdl.h:106:36: note: previous declaration of ‘lt__PROGRAM__LTX_preloaded_symbols’ was here
the declaration is provided by ltld.h of libtool since version 2.4, require the 2.4 instead of 2.2
Signed-off-by: Peter Meerwald <p.meerwald@bct-electronic.com>
Instead of repeatedly asking the discovery API to find a transport given
our transport path, let's hold a pointer to the transport and make sure
we remove the reference when the hook is fired reporting that the
transport has been removed. This makes the code easier to follow and
slightly more efficient.
The recently added hook can be used to detect that the transport being
used has been removed. In this case, the profile needs to be set to off.
Additionally, the change fixes a significant problem: without this
transition, the transport could be destroyed while the hook slots (i.e.
nrec_changed_slot) were still set. This led to a double free of these
objects in stop_thread().
The internal API in bluetooth-util should not use the const qualifier
for operations modifying the transport object. This is specially useful
in order to use the available hooks.
If profile could not be successfully initialized, the card should be
set to PROFILE_OFF automatically. If sinks or sources exist, they need
to be destroyed, therefore stop_thread() is called.
