| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Traditionnal SBC frame header describe encoding parameters for each
frame: nr of blocks, subbands, allocation method, and bitpool. In mSBC,
only one combination of parameter is defined. That combination cannot be
expressed using a traditionnal SBC header. Because of this, a specific
header is defined with 0xAD followed by two reserved zero bytes.
|
| | |
|
| |
|
|
|
|
| |
This patch introduce a new private member which purpose is to encode 15
blocks. It is private to the library and can't be set from standard API.
sbc_init_msbc() function will be defined to set this flag.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SBC analysis handles 8 samples at a time. The optimisation requires 8
samples forming an "odd" block, followed by 8 samples, forming an "even"
block. Until now SBC was used for encoding 4, 8, 12, or 16 blocks in a
frame. Reordering took a frame and for each 16 samples (ie 2 blocks) it
produced one "odd" block and one "even" block.
A mSBC frame encodes 15 blocks of 8 samples. 14 blocks are processed as
before, two at a time. If 8 samples are remaining, it will form the
first half of two blocks (a bit of an "odd" block, and a bit of an
"even" block). When processing the next frame, we detect eight samples
were missing at previous iteration and the two block can be finished.
This reordering is possible because only one sample is moved (x[-7]) AND
the first coefficient in the coef table is 0. Thus x[0] doesn't need to
be set and 0 can be used in calculation instead. Note that x[-7] is not
used in analysis for this block.
see: analysis_consts_fixed8_simd_odd.
To detect that two blocks are not completed, the number of processed
samples can be used. This value is stored in position. position starts
at SBC_X_BUFFER_SIZE-72 and is decremented by 16 as long as two blocks
can be formed. If only 8 samples are remaining in input, then position
is decremented by 8 *arbitrarly*, thus indicating that some samples are
pending. During next frame reordering, position will be decremented by 8
again, back to a 16 multiple.
This logic works for SBC_X_BUFFER_SIZE-72 multiple of 16 and bigger than
8*2*15+72=312 and less than 8*3*15+72=432. The current value of 328
matches this constraint and X buffer is shifted every two frames (30
blocks) in mSBC. This way, we don't need to care about x[-7] when
shifting, we also know that it won't be before X.
|
| |
|
|
|
|
|
|
| |
neon has it's own optimized input reordering. Until this code gets optimized,
the neon assembly code will not work with the mSBC input reordering.
However, the plain C version of mSBC can be used in this case.
This patch makes use of plain C code if the block increment is 1 which is
typical for mSBC.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Until now SBC processed 4 blocks at a time. If we want to process 15
blocks, then we need to break this processing in one block steps. 4
blocks is still default increment.
|
| |
|
|
|
|
|
|
|
| |
Until now, SIMD analysis used to process 4 blocks of 8 samples at a
time. This was implemented using two constant tables: odd and even. This
mean we can only process 4, 8, 12, or 16 blocks par SBC packets.
mSBC requires 15 blocks, so to be able to analyse 1 block, it will be
necessary to know if we are processing an odd or even block. This will
be done with a new member to encoder_state.
|
| |
|
|
|
| |
The long-obsoleted AM_CONFIG_HEADER macro was removed in automake 1.13.
Use AC_CONFIG_HEADERS instead.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Fix spelling errors found using the codespell tool
(https://github.com/lucasdemarchi/codespell).
|
| |
|
|
|
|
| |
"__attribute__((always_inline))" does not replace "inline" and they
still need to be used together. This fixes "always_inline function
might not be inlinable [-Wattributes]" warning in gcc 4.7
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The "(((audio_sample << 1) | 1) << frame->scale_factor[ch][sb])"
part of expression
"frame->sb_sample[blk][ch][sb] =
(((audio_sample << 1) | 1) << frame->scale_factor[ch][sb]) /
levels[ch][sb] - (1 << frame->scale_factor[ch][sb])"
in "sbc_unpack_frame" function can sometimes overflow 32-bit signed int.
This problem can be reproduced by first using bitpool 128 and encoding
some random noise data, and then feeding it to sbc decoder. The obvious
thing to do would be to change "audio_sample" variable type to uint32_t.
However the problem is a little bit more complicated. According
to the section "12.6.2 Scale Factors" of A2DP spec:
scalefactor[ch][sb] = pow(2.0, (scale_factor[ch][sb] + 1))
And according to "12.6.4 Reconstruction of the Subband Samples":
sb_sample[blk][ch][sb] = scalefactor[ch][sb] *
((audio_sample[blk][ch][sb]*2.0+1.0) / levels[ch][sb]-1.0);
Hence the current code for calculating "sb_sample[blk][ch][sb]" is
not quite correct, because it loses one least significant bit of
sample data and passes twice smaller sample values to the synthesis
filter (the filter also deviates from the spec to compensate this).
This all has quite a noticeable impact on audio quality. Moreover,
it makes sense to keep a few extra bits of precision here in order
to minimize rounding errors. So the proposed patch introduces a new
SBCDEC_FIXED_EXTRA_BITS constant and uses uint64_t data type
for intermediate calculations in order to safeguard against
overflows. This patch intentionally addresses only the quality
issue, but performance can be also improved later (like replacing
division with multiplication by reciprocal).
Test for the difference of sbc encoding/decoding roundtrip vs.
the original audio file for joint stereo, bitpool 128, 8 subbands
and http://media.xiph.org/sintel/sintel-master-st.flac sample
demonstrates some quality improvement:
=== before ===
--- comparing original / sbc_encoder.exe + sbcdec ---
stddev: 4.64 PSNR: 82.97 bytes:170495708/170496000
=== after ===
--- comparing original / sbc_encoder.exe + sbcdec ---
stddev: 1.95 PSNR: 90.50 bytes:170495708/170496000
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
There are two reasons for this change:
First: consistency. __asm__ was already used elsewhere in the files, so
using that throughout is cleaner.
Second: both asm and __asm__ are GCC-specific extensions, not defined in
the C standard. When compiling with --std=gnu99 both are recognized, but
when using --std=c99 only __asm__ is recognized to make it perfectly
clear that you're not using some standard C99 construct, but a
GCC-extension.
|
| | |
|
| | |
|
