Skip to contentSkip to conversation

sbc decoder unrolled

Bluez-devel Brad Midgley 2 participants 4 messages Sep 9, 2005 Bluetooth drivers

lore
Share & tools
lore
#0 lore raw

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

#1 lore raw
Quoted 3 lines · Brad Midgley

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

Signature · 19 lines
**********************************************************************
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
#2 lore raw

Steven,

Quoted 2 lines

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...

Quoted 3 lines

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

#3 lore raw
In reply to Steven Singer

Steven

Quoted 3 lines

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