POSIX gurantees >=32bit so it all fits in signed int
Also >=32bit ints are assumed througout the codebase
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
These where intended to maintain the previous behavior before dca_dmix_code()
but it is unclear (to me) which way is correct and no sample seem to trigger
the case, also they are incomplete for the purprose of error checking
Found-by: Niels Möller <nisse@lysator.liu.se>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Also include zero in the table, eliminating a special case in the
decoder.
Signed-off-by: Niels Möller <nisse@southpole.se>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
No initialization is needed in dca_decode_frame, because the next
thing it does is calling dca_parse_frame_header, which takes care of
the needed initialization.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The vector dequantization has a test in a loop preventing effective SIMD
implementation. By moving it out of the loop, this loop can be DSPized.
Therefore, modify the current DSP implementation. In particular, the
DSP implementation no longer has to handle null loop sizes.
The decode_hf implementations have following timings:
For x86 Arrandale:
C SSE SSE2 SSE4
win32: 260 162 119 104
win64: 242 N/A 89 72
The arm NEON optimizations follow in a later patch as external asm. The
now unused check for the y modifier in arm inline asm is removed from
configure.
Based on a patch from Christophe Gisquet.
Unrolling of the m == 0 case avoids a possible use of the uninitilized
value sum when s->predictor_history is not set. I failed to find a
sample for it. It also reduced the cycle count from 220 to 150 on
sandy bridge, x86_64 linux, gcc 4.8.2 compared to his patch.
The scaling factor is constant so it is faster to scale the
FIR coefficients in the tables during compilation.
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
The x86 runs short on registers because numerous elements are not static.
In addition, splitting them allows more optimized code, at least for x86.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
It is currently declared as a macro who is set to inlinable functions,
among which a Neon and a default C implementations.
Add a DSP parameter to each inline function, unused except by the
default C implementation which calls a function from the DSP context.
On an Arrandale CPU, gain for an inlined SSE2 function vs. a call:
- Win32: 29 to 26 cycles
- Win64: 25 to 23 cycles
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The x86 runs short on registers because numerous elements are not static.
In addition, splitting them allows more optimized code, at least for x86.
Arm asm changes by Janne Grunau.
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
For the callable function (as opposed to the inline one):
C SSE SSE2 SSE4
Win32: 47 42 29 26
Win64: 30 33 25 23
The SSE version is neither compiled nor set for ARCH_X86_64, as the
inlinable function takes over.
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
It is currently declared as a macro who is set to inlinable functions,
among which a Neon and a default C implementations.
Add a DSP parameter to each inline function, unused except by the
default C implementation which calls a function from the DSP context.
On an Arrandale CPU, gain for an inlined SSE2 function vs. a call:
- Win32: 29 to 26 cycles
- Win64: 25 to 23 cycles
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
When downmixing 2.1 to 2-channel, if the 2.0 portion is Lt/Rt, sum-difference or dual mono, the actual output will be the same (with the LFE either mixed-in or discarded).
Also, when downmixing an arbitrary layout to 2-channel, if the bitstream contains custom downmix coefficients targeting Lt/Rt, then the output will be Lt/Rt rather than regular Stereo.
The check for (prim_channels > 2) before calling dca_downmix made these
cases unreachable, but now 2.1 layouts will go through the downmix code.
Having dual mono, Lt/Rt and sum-difference layouts print errors when
regular Stereo doesn't seems pointless.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
It was based on an old, seemingly incorrect specification, so default
coefficients were always used anyway.
Signed-off-by: Anton Khirnov <anton@khirnov.net>