more encoder stuff
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann
maintainerHi Brad,
Quoted 2 lines
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.
Quoted 4 lines
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> -
Quoted 6 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Moin,
Am Wed, 24 Nov 2004 22:02:44 -0700 schrieb Brad Midgley:
Quoted 4 lines
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
Signature · 4 lines
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! ~
Marcel Holtmann
maintainerHi Henryk,
Quoted 19 lines
Quoted 4 lines
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 insbc_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
Quoted 8 lines
| time ./sbcenc Uninvited.au > Uninvited.sbc
gives| real 0m36.539s | user 0m27.200s | sys 0m1.500sThat'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.
Quoted 5 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
-----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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Moin,
Am Thu, 25 Nov 2004 07:51:24 +0100 schrieb Marcel Holtmann:
Quoted 3 lines
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.
Signature · 4 lines
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! ~
Marcel Holtmann
maintainerHi Henryk,
Quoted 8 lines
Quoted 3 lines
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 ...
Quoted 7 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
-----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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann
maintainerHi Lars,
Quoted 13 lines
| 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.
Quoted 2 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
-----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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel