Hello Brad,
I've tried recently to run a2play on arm (@~380), well no surprise here,
it looks like there is not enough cpu to deal with fp emulation. Later
I've modified a2play so it can play pre-encoded sbc (sbcend output) to
skip encoding part, but it still far from what I get when run it on PC.
I think there is a synchronization problem somewhere there, hear a lot
of clicks, drops and repetitions. I've tried it with 2 different pairs
of headphones, on Bluewalker and on HP's (iPAQ gadget), and while the
former sound not extremelly bad, the latter sound very crappy (there are
periods when they sound ok, but mostly they are out of sync?). So it
looks like it somehow connected with how the headphone handle timing?
I have a couple of questions:
1) Is there anyone buse with sbc fixed point convertion?
2) Is there anyone with similar problems (out-of-synch sound) and knows
how to solve it (or is it just about tuning the timer?)?
Thanks in advance.
Regards,
Victor.
P.S. I run the same code on PC it sounds good, so should be something to
do with switching platforms?
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Brad
Midgley
Sent: Wednesday, June 15, 2005 19:50 PM
To: [email protected]
Subject: Re: [Bluez-devel] Advanced Audio Distribution Profile (A2DP)
Claudio,
What is it you want to do?
We have prototypes for sending and receiving a2dp. For the desktop, we
need to adapt the a2dp sender to be an alsa plugin. Marcel has done some
work on that.
I've been trying to slim down the floating point operations in the sbc
library so the thing will run on an arm cpu.
see http://bluetooth-alsa.sf.net
Brad
Claudio Takahasi wrote:
> Hi folks,
>=20
> Is there anybody working on Advanced Audio Distribution Profile
(A2DP)?
>=20
>=20
> What are the available tools and software for linux/Bluez that provide
> audio streaming?
>=20
>=20
>=20
> Claudio.
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,=20
> informative Webcasts and more! Get everything you need to get up to=20
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dclick
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclic=
k
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
This e-mail message contains information which is confidential and may be=
privileged. It is intended for use by the addressee only. If you are not=
the intended addressee, we request that you notify the sender immediatel=
y and delete or destroy this e-mail message and any attachment(s), withou=
t copying, saving, forwarding, disclosing or using its contents in any ot=
her way. TomTom N.V., TomTom International BV or any other company belong=
ing to the TomTom group of companies will not be liable for damage relati=
ng to the communication by e-mail of data, documents or any other informa=
tion.
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Henryk
> So now you're going to bigger-than-32-bit integers anyways?
We don't need the full 32 bits. I want to get this working and then play
around with slimming it down.
> Some time ago I already stated that using 32 bit for the floating point
> presentation with 16 bits before the decimal point and 16 bits after
> should be enough. (PCM and reconstructed subband samples should not exceed
> 16 bits and all intermediary values should only be fractions of these
> samples. I might have forgotten one bit for the sign, though.)
yes, i remember your suggestion. the libmad guys took an interesting
approach... they only use 3 bits for the decimal and 28 for the
fractional part. i will look at the range of our computation but it may
be possible to similarly dedicate most of the range to the fractional part.
libmad produces 24-bit audio, another indication it is overkill for us
to have 32-bit numbers.
> But then intermediate results during multiplication need an additional 16
> bits and your platform therefore needs to be able to handle (at least) 48
> bit integers without falling back to floating-point emulation speeds.
multiplying two n-bit numbers results in a 2n-bit product. if we have
16-bit numbers, then the multiply/divide intermediate result would fit
in a tidy 32 bits.
> If it can do that, then of course doing fixed point should be easy:
> Addition, multiplication and shift work unchanged. Each multiplication
> must be followed by a shift right 16 bits. Conversion integer -> fixed
> point or fixed point -> integer is shift left 16 bits or shift right 16
> bits respectively.
yes, exactly. I put inline functions in sbc.h to do the multiply and
divide and add/sub "just work."
Brad
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Moin,
On Wed, 22 Jun 2005, Brad Midgley wrote:
> One strange thing was I had to abandon using int32_t as the native type. For
> some reason, math ops on these things that should have used 64 bits for
> intermediate results instead used 32-bit intermediates. Anyway, using the
> type "int" outright made it work as expected.
So now you're going to bigger-than-32-bit integers anyways?
Some time ago I already stated that using 32 bit for the floating point
presentation with 16 bits before the decimal point and 16 bits after
should be enough. (PCM and reconstructed subband samples should not exceed
16 bits and all intermediary values should only be fractions of these
samples. I might have forgotten one bit for the sign, though.)
But then intermediate results during multiplication need an additional 16
bits and your platform therefore needs to be able to handle (at least) 48
bit integers without falling back to floating-point emulation speeds.
If it can do that, then of course doing fixed point should be easy:
Addition, multiplication and shift work unchanged. Each multiplication
must be followed by a shift right 16 bits. Conversion integer -> fixed
point or fixed point -> integer is shift left 16 bits or shift right 16
bits respectively. And that would be about all we need, I think. (I can't
check right now because my laptop is broken and out for repair since some
time.)
--
Henryk Pl?tz
Gr??e aus Berlin
guys
> I think a function to do the conversion from double to fixed will
> require linking libm (for trunc(double) etc) so hopefully we can avoid it.
duh. this conversion is actually very easy and so i committed an inline
func for doing it.
so i committed the fixed point tables (hopefully the conversion went ok)
and a little helper app that generated them. i am going to have to get
back to this later in the week or next week.
brad
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel
It actually isn't that bad to do multiply and divide ops using fixed
point. I committed a change that provides a config option --enable-fixed
and provides the datatype and inline functions for the basic math ops
and conversions (add and subtract don't need anything special)
I like the flexibility of keeping an LGPL license as long as we can.
I used the explanation in
http://home.rochester.rr.com/ohommes/MathFP/mathfp_bg.html which is a
lot better than trying to figure out or tear out code from mad.
One strange thing was I had to abandon using int32_t as the native type.
For some reason, math ops on these things that should have used 64 bits
for intermediate results instead used 32-bit intermediates. Anyway,
using the type "int" outright made it work as expected.
I think a function to do the conversion from double to fixed will
require linking libm (for trunc(double) etc) so hopefully we can avoid it.
Brad
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
> > as far as integer stuff, should we be doing something like a short floa=
t
> >
> > struct sfloat {
> > int16 mantissa;
> > uint8 exponent;
> > }
> >
> > or a fixed point 32-bit value? any idea what part of the 32 bits would
> > be best to have in front and behind the decimal?
> >
> > i guess i should start by having libsbc keep track of ranges of the
> > different floats so we can figure out where the precision needs to be.
>=20
> Look at how the MAD project does it:
>=20
> http://www.underbit.com/products/mad/
The development version of the speex library which has a lot of fixed
point stuff which generic implementation and some arch specific ones
may be a good place to look too. http://www.speex.org
Pete
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Brad,
> > http://www.underbit.com/products/mad/
> > I think they have the fastest MP3 decoder at the moment.
>
> wow, their fixed-point math looks great. Its range is about +/- 8.0 so I
> just need to run some tests and make sure all the variables and
> intermediate results stay in that range.
it should be, because MP3 and SBC are quite similar.
> in fact, I'd like to drop it in as-is, but is it a non-starter to have a
> GPL component (mad_fixed_t etc) inside our LGPL library (libsbc)? Could
> we just say that apps linked against the integer version of libsbc must
> be GPL? Putting a requirement like this on users of the library wouldn't
> be unprecedented.
I like to name it sbc_fixed_t. We need to re-implement everything by
ourself to match it to our needs. And we can of course put the complete
SBC library under GPL. We might use it only in GPL code anyway.
> argh. it's only a few pages of code but it's perfect for what we're
> doing. did they dredge this out of a computer science algorithms 101
> textbook perchance? :)
I have no idea.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel
> http://www.underbit.com/products/mad/
> I think they have the fastest MP3 decoder at the moment.
wow, their fixed-point math looks great. Its range is about +/- 8.0 so I
just need to run some tests and make sure all the variables and
intermediate results stay in that range.
in fact, I'd like to drop it in as-is, but is it a non-starter to have a
GPL component (mad_fixed_t etc) inside our LGPL library (libsbc)? Could
we just say that apps linked against the integer version of libsbc must
be GPL? Putting a requirement like this on users of the library wouldn't
be unprecedented.
argh. it's only a few pages of code but it's perfect for what we're
doing. did they dredge this out of a computer science algorithms 101
textbook perchance? :)
Brad
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Brad,
> >>i was hoping to get the timing problem hammered by using setitimer.
> >>unfortunately, there still seems to be some dependency on the cpu speed
> >>which is surprising to me. there's a place in the code where the time
> >>period reported by libsbc is multiplied by 87/100. that 87 has to be
> >>tweaked for different cpus :(
> >
> > this is because the encoding itself takes some time. For that we need to
> > encode up to 6 SBC frames in advance.
>
> the way a2play is now, we do preencode. right now it's set so the
> encoder will get ahead by 3 packets (typically 6 frames each?). sigalarm
> fires off regularly to initiate the transmission of one packet.
maybe I should look at the code again and test it.
> as far as integer stuff, should we be doing something like a short float
>
> struct sfloat {
> int16 mantissa;
> uint8 exponent;
> }
>
> or a fixed point 32-bit value? any idea what part of the 32 bits would
> be best to have in front and behind the decimal?
>
> i guess i should start by having libsbc keep track of ranges of the
> different floats so we can figure out where the precision needs to be.
Look at how the MAD project does it:
http://www.underbit.com/products/mad/
I think they have the fastest MP3 decoder at the moment.
Basically using a fixed point uint32_t value should be faster than
dealing with a struct. This is only my impression and it is not verified
by any performance tests.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel
>>i was hoping to get the timing problem hammered by using setitimer.
>>unfortunately, there still seems to be some dependency on the cpu speed
>>which is surprising to me. there's a place in the code where the time
>>period reported by libsbc is multiplied by 87/100. that 87 has to be
>>tweaked for different cpus :(
>
> this is because the encoding itself takes some time. For that we need to
> encode up to 6 SBC frames in advance.
the way a2play is now, we do preencode. right now it's set so the
encoder will get ahead by 3 packets (typically 6 frames each?). sigalarm
fires off regularly to initiate the transmission of one packet.
as far as integer stuff, should we be doing something like a short float
struct sfloat {
int16 mantissa;
uint8 exponent;
}
or a fixed point 32-bit value? any idea what part of the 32 bits would
be best to have in front and behind the decimal?
i guess i should start by having libsbc keep track of ranges of the
different floats so we can figure out where the precision needs to be.
brad
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Brad,
> i was hoping to get the timing problem hammered by using setitimer.
> unfortunately, there still seems to be some dependency on the cpu speed
> which is surprising to me. there's a place in the code where the time
> period reported by libsbc is multiplied by 87/100. that 87 has to be
> tweaked for different cpus :(
this is because the encoding itself takes some time. For that we need to
encode up to 6 SBC frames in advance.
> > You need to encode the SBC frames in advance and then use a timer for
> > sending them. I am working on a ALSA plugin that will do exactly this,
> > but I think that won't help you on your embedded platform.
>
> i'm very excited to see this part. go, Marcel! and hopefully you can let
> us see what this work looks like soon :)
Don't expect any updates this month, because I am too busy with other
things. I will release bluez-utils-2.18 without an updated version of
the plugin. However my plan is to have a basic A2DP plugin and also a
headset plugin working before I am going to the OLS.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Guys,
>>I've tried recently to run a2play on arm (@~380), well no surprise here,
>>it looks like there is not enough cpu to deal with fp emulation. Later
>>I've modified a2play so it can play pre-encoded sbc (sbcend output) to
>>skip encoding part, but it still far from what I get when run it on PC.
the irony is we just overwrote an old a2play that required a preencoded
stream to be piped in :(
>>I think there is a synchronization problem somewhere there, hear a lot
>>of clicks, drops and repetitions. I've tried it with 2 different pairs
>>of headphones, on Bluewalker and on HP's (iPAQ gadget), and while the
>>former sound not extremelly bad, the latter sound very crappy (there are
>>periods when they sound ok, but mostly they are out of sync?). So it
>>looks like it somehow connected with how the headphone handle timing?
i was hoping to get the timing problem hammered by using setitimer.
unfortunately, there still seems to be some dependency on the cpu speed
which is surprising to me. there's a place in the code where the time
period reported by libsbc is multiplied by 87/100. that 87 has to be
tweaked for different cpus :(
i came by the 87 by using my 1.4ghz pentium-M with the hp headset.
the iphono and itech headsets are very forgiving with timing. they also
seem to have the worst problems with audio delay.
>>1) Is there anyone buse with sbc fixed point convertion?
>
> We need an integer only implementation of SBC. I may repeat myself, but
> I am not going to code this. This must be done by someone else.
i started trying to do this with a library (gnu mp). the library is
really meant for arbitrary-sized numbers, and not so great with short
floats. if i had a reference implementation of soft floating point in C,
i could dig into this again. i might try it without but i would have to
reinvent the normalizing floats after multiply/divides.
>>2) Is there anyone with similar problems (out-of-synch sound) and knows
>>how to solve it (or is it just about tuning the timer?)?
yes, we found out pretty soon that the hp headset insists on that "87"
to be tuned for different cpus. maybe there is something wrong with how
i did the timer or maybe itimer is not a great route to go.
i also have an arm board that i am trying to use with this stuff. it can
*receive* audio if the encoder settings are turned way down but can't
transmit a2dp. see
http://bluetooth-alsa.sourceforge.net/embed.html
> You need to encode the SBC frames in advance and then use a timer for
> sending them. I am working on a ALSA plugin that will do exactly this,
> but I think that won't help you on your embedded platform.
i'm very excited to see this part. go, Marcel! and hopefully you can let
us see what this work looks like soon :)
Brad
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Victor,
> I've tried recently to run a2play on arm (@~380), well no surprise here,
> it looks like there is not enough cpu to deal with fp emulation. Later
> I've modified a2play so it can play pre-encoded sbc (sbcend output) to
> skip encoding part, but it still far from what I get when run it on PC.
> I think there is a synchronization problem somewhere there, hear a lot
> of clicks, drops and repetitions. I've tried it with 2 different pairs
> of headphones, on Bluewalker and on HP's (iPAQ gadget), and while the
> former sound not extremelly bad, the latter sound very crappy (there are
> periods when they sound ok, but mostly they are out of sync?). So it
> looks like it somehow connected with how the headphone handle timing?
the Bluewalker is a GCT based headphone and quite easy to satisfy. You
can also stream SBC directly over RFCOMM with rcplay. The HP is Zeevo
based and you really need to get the timing right to hear good sound.
The same applies for the CSR based headphones.
> I have a couple of questions:
>
> 1) Is there anyone buse with sbc fixed point convertion?
We need an integer only implementation of SBC. I may repeat myself, but
I am not going to code this. This must be done by someone else.
> 2) Is there anyone with similar problems (out-of-synch sound) and knows
> how to solve it (or is it just about tuning the timer?)?
You need to encode the SBC frames in advance and then use a timer for
sending them. I am working on a ALSA plugin that will do exactly this,
but I think that won't help you on your embedded platform.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel