[Bluez-devel] more encoder stuff

[Bluez-devel] more encoder stuff

[Brad Midgley]

Guys,

It was fantastic listening to my headset on the bus today. I didn't have 
to deal with the bluetake dongle at all... very nice.

I updated our project page http://bluetooth-alsa.sourceforge.net/

What should I be using if I want to encode live from the computer's 
line-in? (I want to see if encoding on the computer results in shorter 
latency than the bluetake dongle. Watching TV with the headset is 
currently not all that fun because of the delay.)

Henryk, you were saying the reference encoder runs faster. Is there any 
chance they are using vector processing like sse/sse2? Do projects like 
xine and mplayer detect and use a vector processor through a library?

We should get Sonorix to send us a headset for testing. Have you had 
much luck with vendor cooperation, Marcel? Right now in a2play we sort 
of assume the headset will only report one codec and I suspect they 
support mp3 natively. (It's possible they are pulling tricks like 
transcoding into SBC before uploading mp3's to the headset's flash 
memory I guess.)

Brad


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] more encoder stuff

[Marcel Holtmann]

Hi Brad,

> It was fantastic listening to my headset on the bus today. I didn't have 
> to deal with the bluetake dongle at all... very nice.

I updated the a2play program to detect my buggy Aiptek headphone and
activate the non specification conform use of SBC audio. Actually I did
changes at many places in the code, because the parameter sets of some
functions had to be changed. And I also cleaned up some mess that was
generated by Lindent.

> What should I be using if I want to encode live from the computer's 
> line-in? (I want to see if encoding on the computer results in shorter 
> latency than the bluetake dongle. Watching TV with the headset is 
> currently not all that fun because of the delay.)

Maybe something like this might work:

	arecord -f cd -t au /dev/stdout | sbcenc - | a2play <bdaddr> -

> We should get Sonorix to send us a headset for testing. Have you had 
> much luck with vendor cooperation, Marcel? Right now in a2play we sort 
> of assume the headset will only report one codec and I suspect they 
> support mp3 natively. (It's possible they are pulling tricks like 
> transcoding into SBC before uploading mp3's to the headset's flash 
> memory I guess.)

In the past I only talked to Aiptek and they won't send me a headphone
for free and so I finally bought one by myself. Right now I think that I
also need the Bluetake headphone, but I don't like to buy another one by
myself. The Sonorix and also the Logitech (sold as HP model for iPAQs at
the moment) are two other interesting headphones. In general it is no
problem for the companies to donate a bunch of their devices, but you
need to talk to right people. As you might have seen on the BlueZ page
there are some friendly companies. They have no problems in giving away
their hardware to developers for free.

	http://www.bluez.org/sponsors.html

May you simply try to contact Sonorix and put me on CC. If they care
about Linux and Bluetooth they should really know my name. And I think
we need actually three of these headphones. One for each of us.

Another way is if people like our work they may donate some money or buy
one of these devices and send it to us. Anyone feel free to contact me
by private email about this.

To answer your MP3 question, I don't know. At the moment I don't expect
any headphones with more than one codec or even with more than one SEID.
The biggest problem might be that the MP3 codec is not license free, but
SBC is. The total cost calculations for software and hardware (including
the firmware) are different.

Regards

Marcel




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] more encoder stuff

[Henryk Plötz]

[-- Attachment #1: Type: text/plain, Size: 1380 bytes --]

Moin,

Am Wed, 24 Nov 2004 22:02:44 -0700 schrieb Brad Midgley:

> Henryk, you were saying the reference encoder runs faster. Is there
> any chance they are using vector processing like sse/sse2? Do projects
> like xine and mplayer detect and use a vector processor through a
> library?

Nope, that was an error on my side. My file output was awfully slow. I
didn't test with large files since then, though. However, I_did_ profile
it and know that most of the encoding time is spent in sbc_analyze_audio
(no surprise there) in the matrixing, windowing and partial calculation
stages.

I just tested it again with a -O3 compiled sbcenc:

| time wine sbc_encoder.exe -o Uninvited.sbc Uninvited.wav
gives 
| real    0m30.095s
| user    0m18.766s
| sys     0m0.686s

| time ./sbcenc Uninvited.au > Uninvited.sbc
gives
| real    0m36.539s
| user    0m27.200s
| sys     0m1.500s

That's not _too_ bad, especially since they are using dual channel while
we are using stereo (the latter gives smaller file size in this case).

By using CC=icc CFLAGS="-O3 -tpp7 -march=pentium4" I can easily get it
down to
| real    0m19.122s
| user    0m11.272s
| sys     0m1.474s

-- 
Henryk Plötz
Grüße aus Berlin
~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~
~ Help Microsoft fight software piracy: Give Linux to a friend today! ~

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Bluez-devel] more encoder stuff

[Marcel Holtmann]

Hi Henryk,

> > you were saying the reference encoder runs faster. Is there
> > any chance they are using vector processing like sse/sse2? Do projects
> > like xine and mplayer detect and use a vector processor through a
> > library?
> 
> Nope, that was an error on my side. My file output was awfully slow. I
> didn't test with large files since then, though. However, I_did_ profile
> it and know that most of the encoding time is spent in sbc_analyze_audio
> (no surprise there) in the matrixing, windowing and partial calculation
> stages.
> 
> I just tested it again with a -O3 compiled sbcenc:
> 
> | time wine sbc_encoder.exe -o Uninvited.sbc Uninvited.wav
> gives 
> | real    0m30.095s
> | user    0m18.766s
> | sys     0m0.686s
> 
> | time ./sbcenc Uninvited.au > Uninvited.sbc
> gives
> | real    0m36.539s
> | user    0m27.200s
> | sys     0m1.500s
> 
> That's not _too_ bad, especially since they are using dual channel while
> we are using stereo (the latter gives smaller file size in this case).

there exists a switch to sbc_encoder.exe to tell them to use stereo or
joint stereo.

> By using CC=icc CFLAGS="-O3 -tpp7 -march=pentium4" I can easily get it
> down to
> | real    0m19.122s
> | user    0m11.272s
> | sys     0m1.474s

The MAD library (www.underbit.com/products/mad/) is using fixed-point
integer computation. Do you think it is possible to do the same thing
for SBC? Will it give us some extra performance?

Regards

Marcel




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] more encoder stuff

[Lars Grunewaldt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marcel Holtmann wrote:
| Hi Henryk,
|
|
|>>you were saying the reference encoder runs faster. Is there
|>>any chance they are using vector processing like sse/sse2? Do projects
|>>like xine and mplayer detect and use a vector processor through a
|>>library?
|>
|>Nope, that was an error on my side. My file output was awfully slow. I
|>didn't test with large files since then, though. However, I_did_ profile
|>it and know that most of the encoding time is spent in sbc_analyze_audio
|>(no surprise there) in the matrixing, windowing and partial calculation
|>stages.
|>
|>I just tested it again with a -O3 compiled sbcenc:
|>
|>| time wine sbc_encoder.exe -o Uninvited.sbc Uninvited.wav
|>gives
|>| real    0m30.095s
|>| user    0m18.766s
|>| sys     0m0.686s
|>
|>| time ./sbcenc Uninvited.au > Uninvited.sbc
|>gives
|>| real    0m36.539s
|>| user    0m27.200s
|>| sys     0m1.500s
|>
|>That's not _too_ bad, especially since they are using dual channel while
|>we are using stereo (the latter gives smaller file size in this case).
|
|
| there exists a switch to sbc_encoder.exe to tell them to use stereo or
| joint stereo.
|
|
|>By using CC=icc CFLAGS="-O3 -tpp7 -march=pentium4" I can easily get it
|>down to
|>| real    0m19.122s
|>| user    0m11.272s
|>| sys     0m1.474s
|
|
| The MAD library (www.underbit.com/products/mad/) is using fixed-point
| integer computation. Do you think it is possible to do the same thing
| for SBC? Will it give us some extra performance?

just wanted to note that xine and mplayer definitly use mmx/sse in
different versions at least for video encoding/decoding, but I don't
know whether there are split-off libraries available.

The only audio encoding library I ever worked with was PWlib, the
hardware abstraction layer of the openh323 project.

Worked fine for playing/recording audio and decoding/encoding all this
gsm/mu_law stuff you use in VoIP, but I don't think it's well-suited for
the sbc encoder/decoder project.

Just wanted to mention it, though :)

- - Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBpe2hQWC6DTWkDAoRAhCTAKCVOsTh7rc9DhM9aVuu1ryM+fnuqwCgnWSd
lYocn6vmLZG6mFgn+A8tr7g=
=KWh0
-----END PGP SIGNATURE-----


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] more encoder stuff

[Henryk Plötz]

[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]

Moin,

Am Thu, 25 Nov 2004 07:51:24 +0100 schrieb Marcel Holtmann:

> The MAD library (www.underbit.com/products/mad/) is using fixed-point
> integer computation. Do you think it is possible to do the same thing
> for SBC? Will it give us some extra performance?

Unfortunately I'm not familiar with fixed-point arithmetics, especially
with how to handle multiplication. So if anyone who has done this before
would step forward ...

Well, I did some naive tests: I probably did something wrong, but I'm
not seeing any significant difference between floating point and fixed
point (that is: integer). For multiplication the difference is not
noticeable (1.38s vs. 1.36s in my test program) and for addition it is
not that big (0.77s vs. 0.47s).

I guess we'll be fine using floating point as long as there is an FPU.

-- 
Henryk Plötz
Grüße aus Berlin
~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~
~ Help Microsoft fight software piracy: Give Linux to a friend today! ~

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Bluez-devel] more encoder stuff

[Marcel Holtmann]

Hi Henryk,

> > The MAD library (www.underbit.com/products/mad/) is using fixed-point
> > integer computation. Do you think it is possible to do the same thing
> > for SBC? Will it give us some extra performance?
> 
> Unfortunately I'm not familiar with fixed-point arithmetics, especially
> with how to handle multiplication. So if anyone who has done this before
> would step forward ...
> 
> Well, I did some naive tests: I probably did something wrong, but I'm
> not seeing any significant difference between floating point and fixed
> point (that is: integer). For multiplication the difference is not
> noticeable (1.38s vs. 1.36s in my test program) and for addition it is
> not that big (0.77s vs. 0.47s).
> 
> I guess we'll be fine using floating point as long as there is an FPU.

we can optimize at any time if needed, because the SBC API should hide
this stuff. For me this sounds perfect for a diploma thesis for someone
interested in audio codec stuff and Bluetooth.

Regards

Marcel




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] more encoder stuff

[Lars Grunewaldt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marcel Holtmann wrote:
| Hi Henryk,
|
|
|>>The MAD library (www.underbit.com/products/mad/) is using fixed-point
|>>integer computation. Do you think it is possible to do the same thing
|>>for SBC? Will it give us some extra performance?
|>
|>Unfortunately I'm not familiar with fixed-point arithmetics, especially
|>with how to handle multiplication. So if anyone who has done this before
|>would step forward ...
|>
|>Well, I did some naive tests: I probably did something wrong, but I'm
|>not seeing any significant difference between floating point and fixed
|>point (that is: integer). For multiplication the difference is not
|>noticeable (1.38s vs. 1.36s in my test program) and for addition it is
|>not that big (0.77s vs. 0.47s).
|>
|>I guess we'll be fine using floating point as long as there is an FPU.
|
|
| we can optimize at any time if needed, because the SBC API should hide
| this stuff. For me this sounds perfect for a diploma thesis for someone
| interested in audio codec stuff and Bluetooth.

*raising hand*

thing is, on modern CPU you won't get much speedup with fixed point
stuff, because the main advantage was eliminated by Intel when they
build the pseudo-pipes into their FPU's. That's why id used floating
point operations for gfx for the first time, making life for non-Pentium
owners really hard. AMD also has the pseudo-pipes, and modern
multiplication/devision on FPU is very fast.

But of course there are still some cycles to kill in audio processing
always. I'll advertise this project to my professor...

cu,
~  Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBpnVHQWC6DTWkDAoRAgkgAKDAZ9hRDYGRP4sNtuJKFFu/0zcomQCgmG8v
UoPSMR/LGba03dC7OsdwkUM=
=vL5b
-----END PGP SIGNATURE-----


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] more encoder stuff

[Marcel Holtmann]

Hi Lars,

> | we can optimize at any time if needed, because the SBC API should hide
> | this stuff. For me this sounds perfect for a diploma thesis for someone
> | interested in audio codec stuff and Bluetooth.
> 
> *raising hand*
> 
> thing is, on modern CPU you won't get much speedup with fixed point
> stuff, because the main advantage was eliminated by Intel when they
> build the pseudo-pipes into their FPU's. That's why id used floating
> point operations for gfx for the first time, making life for non-Pentium
> owners really hard. AMD also has the pseudo-pipes, and modern
> multiplication/devision on FPU is very fast.
> 
> But of course there are still some cycles to kill in audio processing
> always. I'll advertise this project to my professor...

a non floating point version is interesting for embedded platforms and
not all desktops are running with a 3 GHz processor. I think what the
MAD library does is very good and their MP3 decoding is fast. Running
top shows a very nice CPU load. However we can't simply copy their
stuff, because their code is under GPL only and I wanna keep the SBC
library under LGPL.

Regards

Marcel




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] more encoder stuff

[Lars Grunewaldt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marcel Holtmann wrote:
| Hi Lars,
|
|
|>| we can optimize at any time if needed, because the SBC API should hide
|>| this stuff. For me this sounds perfect for a diploma thesis for someone
|>| interested in audio codec stuff and Bluetooth.
|>
|>*raising hand*
|>
|>thing is, on modern CPU you won't get much speedup with fixed point
|>stuff, because the main advantage was eliminated by Intel when they
|>build the pseudo-pipes into their FPU's.
|>But of course there are still some cycles to kill in audio processing
|>always. I'll advertise this project to my professor...
|
|
| a non floating point version is interesting for embedded platforms

good argument

| and
| not all desktops are running with a 3 GHz processor. I think what the
| MAD library does is very good and their MP3 decoding is fast.

Depending on the purpose of the calculations fixed point calculations
add an overhead that can - in some situations - eat up the speed gain
compared to true fpu.

But as you said, not all systems run on CPU/FPU combinations with the
specs of a modern desktop computer, and in fact this is important for
bluetooth stuff as many portable devices also use linux nowadays.

So I think we both have a point, but yours matches the BlueZ situation
much better than mine :)

Not used to it. Strange enough, as I program for PalmOS quite a lot...

cu,
~  Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBpn93QWC6DTWkDAoRAhETAJ9dthtjsNEM0Acxt3GSDVmzg8g/kACgg644
eNFC/R0TmjKb9hKu0Y5fR00=
=2HW2
-----END PGP SIGNATURE-----


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel