[Bluez-users] How to use sbc.c of btsco?

Discussion:

Brad Midgley

2006-12-16 07:28:32 UTC

Frank

fyi, I moved the reply to bluez-devel.

sbc_encode: It seems like you put pcm data on 'data' and get sbc data in
'sbc.data'. 'count' is not used in the function. How often must I call
it? How do I know how much of 'data' is converted already?

the return value from sbc_encode is the number of bytes consumed. It's
true that count is not used properly. In fact we assume there is enough
data there to fill one sbc frame.

sbc_decode: Put sbc data on 'data' and you get pcm data in 'sbc.m.data'.
Is that right? Must I always change the byte order like it is done in
a2recv.c?

The swapping was to accommodate bugs in the audio driver's endian
processing on gumstix. You can ignore it.

Are there special things to do if I have a .wav file or do I just have
to call the functions? I am just talking of the payload and not the headers.

be sure you init the encoder with the correct channels (1 or 2) and
sample rate. after that just be sure to pass enough data to sbc_encode
in each pass so it doesn't underrun.

It would help me a lot if somebody could put me on the right track.

Be sure you are using the separate sbc sourceforge project since that's
the version of the codec we are maintaining. Finally, we'd appreciate
any patches you come up with to improve the code documentation or even
more if you address any of the limitations. Documentation of course is a
problem, but there's also a todo list at the top of sbc.c.

Brad

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Frank Heimbächer

2006-12-19 11:43:13 UTC

Permalink

Thanks a lot, Brad.

What succeeded: With an older version of sbc.c I managed to encode a wav
file, send it over the air and receive it, decode it and write it in a
file. Well, it looks different than the original. In the original there
is some information in the first bytes like: "WAVEfmt", a long area with
zero bytes, then the characters "data" and then the data seems to begin.
I do not find this in my received file. Is there something else I have
to care about? Should I run sbcinfo and change sbc_init() according to
the results?

The newest download of sbc.c from http://sbc.cvs.sourceforge.net/sbc/
under menu "CVS Browse" contains a simple bug, which lets the file
compile, but crash on runtime: In function _sbc_analyze_eight() the
array 't[8]' is referenced from t[1] to t[8], instead of t[0] to t[7].

Thanks a lot
Frank

Post by Brad Midgley
Frank
fyi, I moved the reply to bluez-devel.

the return value from sbc_encode is the number of bytes consumed. It's
true that count is not used properly. In fact we assume there is enough
data there to fill one sbc frame.

sbc_decode: Put sbc data on 'data' and you get pcm data in 'sbc.m.data'.
Is that right? Must I always change the byte order like it is done in
a2recv.c?

The swapping was to accommodate bugs in the audio driver's endian
processing on gumstix. You can ignore it.

Are there special things to do if I have a .wav file or do I just have
to call the functions? I am just talking of the payload and not the headers.

be sure you init the encoder with the correct channels (1 or 2) and
sample rate. after that just be sure to pass enough data to sbc_encode
in each pass so it doesn't underrun.

It would help me a lot if somebody could put me on the right track.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Brad Midgley

2006-12-19 22:17:21 UTC

Permalink

Frank

Post by Frank HeimbÃ¤cher
What succeeded: With an older version of sbc.c I managed to encode a wav
file, send it over the air and receive it, decode it and write it in a
file. Well, it looks different than the original. In the original there
is some information in the first bytes like: "WAVEfmt", a long area with
zero bytes, then the characters "data" and then the data seems to begin.
I do not find this in my received file. Is there something else I have
to care about? Should I run sbcinfo and change sbc_init() according to
the results?

there is not a way to send metadata about the original wav over the a2dp
stream. It sounds like you want a way to create a wav from the pcm
received on the other side. You will have to use a conversion utility.

Post by Frank HeimbÃ¤cher
The newest download of sbc.c from http://sbc.cvs.sourceforge.net/sbc/
under menu "CVS Browse" contains a simple bug, which lets the file
compile, but crash on runtime: In function _sbc_analyze_eight() the
array 't[8]' is referenced from t[1] to t[8], instead of t[0] to t[7].

fixed. thanks.

Brad

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Frédéric DALLEAU

2006-12-20 13:14:07 UTC

Permalink

Brad,

Post by Brad Midgley

fixed. thanks.

--
Frederic

Without the wind, the grass does not move.

Brad Midgley

2007-01-10 20:32:27 UTC

Permalink

Frédéric

Somehow this message went to my junk folder!

The tables we have are different because we have changed the algorithm
over time and adapted the tables to avoid some computation. We also
split the tables as a result of how they are used.

On top of that, we converted the values to integers which doesn't help
make it easy to follow.

I hope it's not impossible to follow :(

Brad

Post by FrÃ©dÃ©ric DALLEAU

Post by Brad Midgley

fixed. thanks.

some values were missed so the sound is now larsenized ;)
patch attached.
BTW, I was looking for the tables specially Proto_4_40 and Proto_8_80
from a2dp specifications.
I suspect they are stored in sbc_proto_8_80m0 and sbc_proto_8_80m1.
The values are not the same that in the spec. Do you know why?
------------------------------------------------------------------------
? Doxyfile
? Makefile
? Makefile.in
? aclocal.m4
? autom4te.cache
? config.guess
? config.h
? config.h.in
? config.log
? config.status
? config.sub
? configure
? debug
? depcomp
? install-sh
? libtool
? ltmain.sh
? missing
? sbc.kdevelop
? sbc.kdevelop.pcs
? sbc.kdevses
? sbc.pc
? stamp-h1
? include/Makefile
? include/Makefile.in
? lib/.deps
? lib/.libs
? lib/Makefile
? lib/Makefile.in
? lib/libsbc.la
? lib/sbc.lo
? src/.deps
? src/.libs
? src/Makefile
? src/Makefile.in
? src/sbcinfo
Index: lib/sbc.c
===================================================================
RCS file: /cvsroot/sbc/sbc/lib/sbc.c,v
retrieving revision 1.8
diff -u -r1.8 sbc.c
--- lib/sbc.c 19 Dec 2006 22:13:41 -0000 1.8
+++ lib/sbc.c 20 Dec 2006 12:58:09 -0000
@@ -892,84 +892,84 @@
MULA(res, -_sbc_proto_8[21], in[75]);
t[7] = SCALE8_STAGE1(res);
- MUL(res, _anamatrix8[0], t[1]);
- MULA(res, _anamatrix8[7], t[2]);
- MULA(res, _anamatrix8[2], t[3]);
- MULA(res, _anamatrix8[3], t[4]);
- MULA(res, _anamatrix8[6], t[5]);
- MULA(res, _anamatrix8[4], t[6]);
- MULA(res, _anamatrix8[1], t[7]);
- MULA(res, _anamatrix8[5], t[8]);
+ MUL(res, _anamatrix8[0], t[0]);
+ MULA(res, _anamatrix8[7], t[1]);
+ MULA(res, _anamatrix8[2], t[2]);
+ MULA(res, _anamatrix8[3], t[3]);
+ MULA(res, _anamatrix8[6], t[4]);
+ MULA(res, _anamatrix8[4], t[5]);
+ MULA(res, _anamatrix8[1], t[6]);
+ MULA(res, _anamatrix8[5], t[7]);
out[0] = SCALE8_STAGE2(res);
- MUL(res, _anamatrix8[1], t[1]);
- MULA(res, _anamatrix8[7], t[2]);
- MULA(res, _anamatrix8[3], t[3]);
- MULA(res, -_anamatrix8[5], t[4]);
- MULA(res, -_anamatrix8[6], t[5]);
- MULA(res, -_anamatrix8[2], t[6]);
- MULA(res, -_anamatrix8[0], t[7]);
- MULA(res, -_anamatrix8[4], t[8]);
+ MUL(res, _anamatrix8[1], t[0]);
+ MULA(res, _anamatrix8[7], t[1]);
+ MULA(res, _anamatrix8[3], t[2]);
+ MULA(res, -_anamatrix8[5], t[3]);
+ MULA(res, -_anamatrix8[6], t[4]);
+ MULA(res, -_anamatrix8[2], t[5]);
+ MULA(res, -_anamatrix8[0], t[6]);
+ MULA(res, -_anamatrix8[4], t[7]);
out[1] = SCALE8_STAGE2(res);
- MUL(res, -_anamatrix8[1], t[1]);
- MULA(res, _anamatrix8[7], t[2]);
- MULA(res, _anamatrix8[4], t[3]);
- MULA(res, -_anamatrix8[2], t[4]);
- MULA(res, -_anamatrix8[6], t[5]);
- MULA(res, _anamatrix8[5], t[6]);
- MULA(res, _anamatrix8[0], t[7]);
- MULA(res, _anamatrix8[3], t[8]);
+ MUL(res, -_anamatrix8[1], t[0]);
+ MULA(res, _anamatrix8[7], t[1]);
+ MULA(res, _anamatrix8[4], t[2]);
+ MULA(res, -_anamatrix8[2], t[3]);
+ MULA(res, -_anamatrix8[6], t[4]);
+ MULA(res, _anamatrix8[5], t[5]);
+ MULA(res, _anamatrix8[0], t[6]);
+ MULA(res, _anamatrix8[3], t[7]);
out[2] = SCALE8_STAGE2(res);
- MUL(res, -_anamatrix8[0], t[1]);
- MULA(res, _anamatrix8[7], t[2]);
- MULA(res, _anamatrix8[5], t[3]);
- MULA(res, -_anamatrix8[4], t[4]);
- MULA(res, _anamatrix8[6], t[5]);
- MULA(res, _anamatrix8[3], t[6]);
- MULA(res, -_anamatrix8[1], t[7]);
- MULA(res, -_anamatrix8[2], t[8]);
+ MUL(res, -_anamatrix8[0], t[0]);
+ MULA(res, _anamatrix8[7], t[1]);
+ MULA(res, _anamatrix8[5], t[2]);
+ MULA(res, -_anamatrix8[4], t[3]);
+ MULA(res, _anamatrix8[6], t[4]);
+ MULA(res, _anamatrix8[3], t[5]);
+ MULA(res, -_anamatrix8[1], t[6]);
+ MULA(res, -_anamatrix8[2], t[7]);
out[3] = SCALE8_STAGE2(res);
- MUL(res, -_anamatrix8[0], t[1]);
- MULA(res, _anamatrix8[7], t[2]);
- MULA(res, -_anamatrix8[5], t[3]);
- MULA(res, _anamatrix8[4], t[4]);
- MULA(res, _anamatrix8[6], t[5]);
- MULA(res, -_anamatrix8[3], t[6]);
- MULA(res, -_anamatrix8[1], t[7]);
- MULA(res, _anamatrix8[2], t[8]);
+ MUL(res, -_anamatrix8[0], t[0]);
+ MULA(res, _anamatrix8[7], t[1]);
+ MULA(res, -_anamatrix8[5], t[2]);
+ MULA(res, _anamatrix8[4], t[3]);
+ MULA(res, _anamatrix8[6], t[4]);
+ MULA(res, -_anamatrix8[3], t[5]);
+ MULA(res, -_anamatrix8[1], t[6]);
+ MULA(res, _anamatrix8[2], t[7]);
out[4] = SCALE8_STAGE2(res);
- MUL(res, -_anamatrix8[1], t[1]);
- MULA(res, _anamatrix8[7], t[2]);
- MULA(res, -_anamatrix8[4], t[3]);
- MULA(res, _anamatrix8[2], t[4]);
- MULA(res, -_anamatrix8[6], t[5]);
- MULA(res, -_anamatrix8[5], t[6]);
- MULA(res, _anamatrix8[0], t[7]);
- MULA(res, -_anamatrix8[3], t[8]);
+ MUL(res, -_anamatrix8[1], t[0]);
+ MULA(res, _anamatrix8[7], t[1]);
+ MULA(res, -_anamatrix8[4], t[2]);
+ MULA(res, _anamatrix8[2], t[3]);
+ MULA(res, -_anamatrix8[6], t[4]);
+ MULA(res, -_anamatrix8[5], t[5]);
+ MULA(res, _anamatrix8[0], t[6]);
+ MULA(res, -_anamatrix8[3], t[7]);
out[5] = SCALE8_STAGE2(res);
- MUL(res, _anamatrix8[1], t[1]);
- MULA(res, _anamatrix8[7], t[2]);
- MULA(res, -_anamatrix8[3], t[3]);
- MULA(res, _anamatrix8[5], t[4]);
- MULA(res, -_anamatrix8[6], t[5]);
- MULA(res, _anamatrix8[2], t[6]);
- MULA(res, -_anamatrix8[0], t[7]);
- MULA(res, _anamatrix8[4], t[8]);
+ MUL(res, _anamatrix8[1], t[0]);
+ MULA(res, _anamatrix8[7], t[1]);
+ MULA(res, -_anamatrix8[3], t[2]);
+ MULA(res, _anamatrix8[5], t[3]);
+ MULA(res, -_anamatrix8[6], t[4]);
+ MULA(res, _anamatrix8[2], t[5]);
+ MULA(res, -_anamatrix8[0], t[6]);
+ MULA(res, _anamatrix8[4], t[7]);
out[6] = SCALE8_STAGE2(res);
- MUL(res, _anamatrix8[0], t[1]);
- MULA(res, _anamatrix8[7], t[2]);
- MULA(res, -_anamatrix8[2], t[3]);
- MULA(res, -_anamatrix8[3], t[4]);
- MULA(res, _anamatrix8[6], t[5]);
- MULA(res, -_anamatrix8[4], t[6]);
- MULA(res, _anamatrix8[1], t[7]);
- MULA(res, -_anamatrix8[5], t[8]);
+ MUL(res, _anamatrix8[0], t[0]);
+ MULA(res, _anamatrix8[7], t[1]);
+ MULA(res, -_anamatrix8[2], t[2]);
+ MULA(res, -_anamatrix8[3], t[3]);
+ MULA(res, _anamatrix8[6], t[4]);
+ MULA(res, -_anamatrix8[4], t[5]);
+ MULA(res, _anamatrix8[1], t[6]);
+ MULA(res, -_anamatrix8[5], t[7]);
out[7] = SCALE8_STAGE2(res);
}
------------------------------------------------------------------------
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
------------------------------------------------------------------------
_______________________________________________
Bluez-devel mailing list
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Siegbert Baude

2007-01-11 08:24:00 UTC

Permalink

Hello Brad,

Post by Brad Midgley
The tables we have are different because we have changed the algorithm
over time and adapted the tables to avoid some computation. We also
split the tables as a result of how they are used.
On top of that, we converted the values to integers which doesn't help
make it easy to follow.
I hope it's not impossible to follow :(

At least it's difficult. ;-)
Maybe a short comment line would be nice which describes the steps from
the original tables to the ones found in the code. The perfect solution
would be the original matrix in the code and some pre-processor magic to
calculate the derived ones during compile time. If you describe the
necessary steps I could have a look at it, because I need to optimize
the synthesize methods for our project on a fixed-point DSP anyways.

Best regards
Siegbert

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Brad Midgley

2007-01-16 04:33:58 UTC

Permalink

Siegbert

Post by Siegbert Baude
At least it's difficult. ;-)
Maybe a short comment line would be nice which describes the steps from
the original tables to the ones found in the code. The perfect solution
would be the original matrix in the code and some pre-processor magic to
calculate the derived ones during compile time. If you describe the
necessary steps I could have a look at it, because I need to optimize
the synthesize methods for our project on a fixed-point DSP anyways.

I've been trying to fix some problems in there and I will reconstruct as
much as I can from memory and comment it.

Brad

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Frédéric DALLEAU

2007-01-11 08:35:41 UTC

Permalink

Brad,

Thank you for answering, I was hesitating between precalculation or
custom tables.

I've not been really deep into the codec now. It's not easy to follow as
the spec itself could be more clear.

In my investigations, I got over a 64 bits version of the codec. I
tested it on pc and arm. It gave better results than the 32 bits : the
gain is better, the overflow do not occurs, there is still a bit of
background noise, but not more than the 32 bits and it may be the sample
file. It will probably consume a little bit more cpu, but I found this
was not really noticeable (at least on my hardware). But the library
could be changed according to needs.

While this is not the best solution to the problem, I still think users
are complaining mainly about gain. So it could be possible to provide it
as default. What about you?

Regards,
Frédéric.

Post by Brad Midgley
Frédéric
Somehow this message went to my junk folder!
The tables we have are different because we have changed the algorithm
over time and adapted the tables to avoid some computation. We also
split the tables as a result of how they are used.
On top of that, we converted the values to integers which doesn't help
make it easy to follow.
I hope it's not impossible to follow :(
Brad

Post by Brad Midgley

fixed. thanks.

--
Frederic

Without the wind, the grass does not move.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Brad Midgley

2007-01-12 18:52:16 UTC

Permalink

Frédéric

Post by FrÃ©dÃ©ric DALLEAU
In my investigations, I got over a 64 bits version of the codec. I
tested it on pc and arm. It gave better results than the 32 bits : the
gain is better, the overflow do not occurs, there is still a bit of
background noise, but not more than the 32 bits and it may be the sample
file. It will probably consume a little bit more cpu, but I found this
was not really noticeable (at least on my hardware). But the library
could be changed according to needs.
While this is not the best solution to the problem, I still think users
are complaining mainly about gain. So it could be possible to provide it
as default. What about you?

We have confirmation that this stuff can be done in 32 bits but it is
more work to get it right. I thought I was getting close back when I was
working on it last but couldn't get over those volume/overflow problems.
I do think the decoder was working ok in 32 bits at least.

We used to run everything in 64 bits. btsco/sbc would have the cvs
history showing the older stuff.

How about if we create a separate cvs module like "sbc64" that contains
libsbc with a 64-bit encoder? I don't like having the implementations
together with a bunch of conditional code choosing one over the other.
That was really ugly and too easy to break.

Brad

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Frederic Dalleau

2007-01-13 17:32:18 UTC

Permalink

Brad

Post by Brad Midgley
How about if we create a separate cvs module like "sbc64" that contains
libsbc with a 64-bit encoder?

I fully agree!
Should the two library coexist?

Frédéric

Brad Midgley

2007-01-16 04:25:04 UTC

Permalink

Frederic

I don't think they should need to coexist. We'll choose one or the other
and it'll create the same shared objects. They do need to stay
binary/api compatible to pull that off though.

Post by Frederic Dalleau

Post by Brad Midgley
How about if we create a separate cvs module like "sbc64" that contains
libsbc with a 64-bit encoder?

I fully agree!
Should the two library coexist?

Brad

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Frank Heimbaecher

2006-12-22 12:07:41 UTC

Permalink

Hello

I found out that sbc.c, as it is, works for big endian. On little endian
machines you cannot recognize an audio file after encoding and decoding.
So I changed the code a bit:

sbc_decode():
// fh 20.12.06: original source code assumes big endian
// so we have to change the order of the following 2 statements
*ptr++ = (s & 0x00ff);
*ptr++ = (s & 0xff00) >> 8;

sbc_encode():
// fh 20.12.06: original source code assumes big endian
// so we have to exchange [0] and [1] here
int16_t s = (ptr[1] & 0xff) << 8 | (ptr[0] & 0xff);

Would it be a suggestion to work with a macro LITTLE_ENDIAN here?

And very interesting for me: Are there other places in the code that
need to be adapted to little endian? Because the result after decoding
is still poor: volume is too low, speed is too high (probably data
missing) and sound is quite shallow. When I write the resulting data to
a file, it is smaller than the original.

Thanks for help
Frank
--
Dipl.-Inform. Frank Heimbaecher, Senior Software Architect

jambit Software Development & Management GmbH
Nymphenburger Strasse 13-15, D-80335 Muenchen

http://www.jambit.com where innovation works

Tel.: +49.89.45 2347-42
Fax: +49.89.45 2347-70

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV