Hey
woohoo... I worked over the decoder a lot more and finally unrolled &
committed it. It still uses floating point for now.
I was very proud of the fact that I found a way to rotate which
sbc_proto_x_x0 value we choose rather than shifting matrixed values
around in every loop. It's even more clear that the implementation they
illustrate in the spec is meant to make the algorithm clear but not be
an efficient way to do it.
I don't know how the instruction cache size in arm compares to x86. I
haven't checked to see yet if unrolling is as big a win on xscale. fwiw,
it cut x86 cpu use by about 50% over the looped code.
I'll look at fixed point next.
Brad
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Steven
> output of reference encoder + your decoder (spec requires K > 14)
> output of your encoder + reference decoder
> output of your encoder + your decoder
There is a little gotcha here in that we only have a windows binary for
a reference encoder/decoder. I haven't tried to build our stuff in
cygwin or windows dev tools and there are probably things to fix...
Brad
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Steven,
> threshold. (For qualification, they talk about the decoder having a K
> value which needs to be greater than 14).
I had given up on regression tests for accuracy and performance because
I didn't know about K values and I figured x86 performance might
actually go down for fixed point (Victor confirmed this)
Google isn't helping me find much about K value this morning but I would
like to put a regression test in the build if we find something...
> As well as measuring K, you should also listen to the outputs -
> otherwise you may have a bug that sounds bad but somehow manages to
> pass the K test.
Yes... the only thing worse than listening to the reference streams for
the thousandth time is listening to the reference streams again with
some new distortion introduced. I ended up encoding some music snipets
for testing that I (used to) like to listen to :)
thanks for the input
Brad
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Brad Midgley wrote:
> It's even more clear that the implementation they
> illustrate in the spec is meant to make the algorithm clear but not be
> an efficient way to do it.
This is definitely true.
The spec allows you complete flexibility on your implementation. You're
not even obliged to use the algorithm in the spec. You need make sure
only that the errors between the outputs of your encoder and decoder and
the outputs of the reference encoder and decoder are less than a
threshold. (For qualification, they talk about the decoder having a K
value which needs to be greater than 14).
If you have a program that can calculate K, then I suggest that a
suitable regression test is to measure the K values of the reference
test inputs between:
output of reference encoder + reference decoder
and each of:
output of reference encoder + your decoder (spec requires K > 14)
output of your encoder + reference decoder
output of your encoder + your decoder
This gives you much more optimisation flexibility than requiring an
identical output bit stream.
As well as measuring K, you should also listen to the outputs -
otherwise you may have a bug that sounds bad but somehow manages to
pass the K test.
Remember SBC is a lossy codec, it'd be pointless to try too hard to
precisely reproduce the losses of the reference codec.
- Steven
--
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
**********************************************************************
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel