[Bluez-devel] Advanced Audio Distribution Profile (A2DP)

[Bluez-devel] Advanced Audio Distribution Profile (A2DP)

[Claudio Takahasi]

Hi folks,

Is there anybody working on Advanced Audio Distribution Profile (A2DP)?


What are the available tools and software for linux/Bluez that
provide audio streaming?



Claudio.


-------------------------------------------------------
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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Advanced Audio Distribution Profile (A2DP)

[wim delvaux]

On Wednesday 15 June 2005 19:19, Claudio Takahasi wrote:
> Hi folks,
>
> Is there anybody working on Advanced Audio Distribution Profile (A2DP)?
>
>
> What are the available tools and software for linux/Bluez that
> provide audio streaming?

a2play

http://bluetooth-alsa.sourceforge.net/



>
>
>
> Claudio.
>
>
> -------------------------------------------------------
> 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_idt77&alloc_id\x16492&op=Click
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> 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=7477&alloc_id=16492&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Advanced Audio Distribution Profile (A2DP)

[Brad Midgley]

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,
> 
> Is there anybody working on Advanced Audio Distribution Profile (A2DP)?
> 
> 
> What are the available tools and software for linux/Bluez that
> provide audio streaming?
> 
> 
> 
> Claudio.
> 
> 
> -------------------------------------------------------
> 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_idt77&alloc_id\x16492&op=click
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> 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=7477&alloc_id=16492&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Advanced Audio Distribution Profile (A2DP)

[Henryk Plötz]

Moin,

On Wed, 15 Jun 2005, Claudio Takahasi wrote:

> Is there anybody working on Advanced Audio Distribution Profile (A2DP)?

Well, probably not exactly at this moment, but in general: yes.

> What are the available tools and software for linux/Bluez that
> provide audio streaming?

A2DP is an experimental part of bluetooth-alsa, take a look at
http://bluetooth-alsa.sf.net/. All relevant explanations should be on that
page.

--=20
Henryk Pl=F6tz
Gr=FC=DFe aus Berlin


-------------------------------------------------------
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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Advanced Audio Distribution Profile (A2DP)

[Claudio Takahasi]

Thanks for all answer!

At first moment I want setup a motorola HS810 to working on Linux and
after that analise how can it work on embedded linux.


Regards,
Claudio.

On 6/15/05, Henryk Pl=F6tz <henryk@ploetzli.ch> wrote:
> Moin,
>=20
> On Wed, 15 Jun 2005, Claudio Takahasi wrote:
>=20
> > Is there anybody working on Advanced Audio Distribution Profile (A2DP)?
>=20
> Well, probably not exactly at this moment, but in general: yes.
>=20
> > What are the available tools and software for linux/Bluez that
> > provide audio streaming?
>=20
> A2DP is an experimental part of bluetooth-alsa, take a look at
> http://bluetooth-alsa.sf.net/. All relevant explanations should be on tha=
t
> page.
>=20
> --
> Henryk Pl=F6tz
> Gr=FC=DFe aus Berlin
>


-------------------------------------------------------
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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Advanced Audio Distribution Profile (A2DP)

[Peter Robinson]

> Thanks for all answer!
>=20
> At first moment I want setup a motorola HS810 to working on Linux and
> after that analise how can it work on embedded linux.

Umm. Maybe its just early in the morning but isn't the A2DP for stereo
audio while the HS-810 is mono with a mic and hence uses the SCO audio
which is different. Although the fixed point stuff probably still
applies.

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

RE: [Bluez-devel] Advanced Audio Distribution Profile (A2DP)

[Victor Shcherbatyuk]

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: bluez-devel-admin@lists.sourceforge.net
[mailto:bluez-devel-admin@lists.sourceforge.net] On Behalf Of Brad
Midgley
Sent: Wednesday, June 15, 2005 19:50 PM
To: bluez-devel@lists.sourceforge.net
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
> Bluez-devel@lists.sourceforge.net
> 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
Bluez-devel@lists.sourceforge.net
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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

RE: [Bluez-devel] Advanced Audio Distribution Profile (A2DP)

[Marcel Holtmann]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Advanced Audio Distribution Profile (A2DP)

[Brad Midgley]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Advanced Audio Distribution Profile (A2DP)

[Marcel Holtmann]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Advanced Audio Distribution Profile (A2DP)

[Brad Midgley]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Advanced Audio Distribution Profile (A2DP)

[Marcel Holtmann]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Advanced Audio Distribution Profile (A2DP)

[Brad Midgley]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Advanced Audio Distribution Profile (A2DP)

[Marcel Holtmann]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Advanced Audio Distribution Profile (A2DP)

[Brad Midgley]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Advanced Audio Distribution Profile (A2DP)

[Brad Midgley]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Advanced Audio Distribution Profile (A2DP)

[Henryk Plötz]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1474 bytes --]

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

Re: [Bluez-devel] Advanced Audio Distribution Profile (A2DP)

[Brad Midgley]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Advanced Audio Distribution Profile (A2DP)

[Peter Robinson]

> > 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. 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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

RE: [Bluez-devel] Advanced Audio Distribution Profile (A2DP)

[Victor Shcherbatyuk]

Hello all,

Today I was playing with the timeout. None of the values I've tried
gives good results for HP headphones. Bigger values as I undestand lead
to a buffer underrun in the headphones (same sound as I get with fp
emulation on), while smaller values  lead to frame(sample?) drops on the
headphone side (it kind of sounds faster, but I thing it just drops the
samples)? The only thing that is stable are breaks in the music I have
now and then. From another side, with Bluewalker, with the magic "87" it
sounds almost the same as with HP headphones (so still break now and
then), but if I reduce timeout by changing e.g. 87 -> 40 it becomes good
and there is no difference from the PC. That makes me think that there
is something to do with the buffering model used for these headphones. I
still want to chek it.

The next step is the fixed point. As I understood Brad is already
looking in to it? Cause I also wanted to look into it somewhere in short
time...

Regards,
       Victor.

-----Original Message-----
From: bluez-devel-admin@lists.sourceforge.net
[mailto:bluez-devel-admin@lists.sourceforge.net] On Behalf Of Brad
Midgley
Sent: Tuesday, June 21, 2005 20:03 PM
To: bluez-devel@lists.sourceforge.net
Subject: Re: [Bluez-devel] Advanced Audio Distribution Profile (A2DP)

i was hoping to get the timing problem hammered by using setitimer.=20
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?
>=20
> We need an integer only implementation of SBC. I may repeat myself,=20
> 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=20
>>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"=20
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=20
> 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=3D7477&alloc_id=3D16492&op=3Dclic=
k
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Advanced Audio Distribution Profile (A2DP)

[Brad Midgley]

Victor,

I am going to have a whack at adding fixed point tables and making the 
decoder optionally use fixed point. I will let you know.

Brad

Victor Shcherbatyuk wrote:
> Hello all,
> 
> Today I was playing with the timeout. None of the values I've tried
> gives good results for HP headphones. Bigger values as I undestand lead
> to a buffer underrun in the headphones (same sound as I get with fp
> emulation on), while smaller values  lead to frame(sample?) drops on the
> headphone side (it kind of sounds faster, but I thing it just drops the
> samples)? The only thing that is stable are breaks in the music I have
> now and then. From another side, with Bluewalker, with the magic "87" it
> sounds almost the same as with HP headphones (so still break now and
> then), but if I reduce timeout by changing e.g. 87 -> 40 it becomes good
> and there is no difference from the PC. That makes me think that there
> is something to do with the buffering model used for these headphones. I
> still want to chek it.
> 
> The next step is the fixed point. As I understood Brad is already
> looking in to it? Cause I also wanted to look into it somewhere in short
> time...
> 
> Regards,
>        Victor.
> 
> -----Original Message-----
> From: bluez-devel-admin@lists.sourceforge.net
> [mailto:bluez-devel-admin@lists.sourceforge.net] On Behalf Of Brad
> Midgley
> Sent: Tuesday, June 21, 2005 20:03 PM
> To: bluez-devel@lists.sourceforge.net
> Subject: Re: [Bluez-devel] Advanced Audio Distribution Profile (A2DP)
> 
> 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
> Bluez-devel@lists.sourceforge.net
> 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 immediately and delete or destroy this e-mail message and any attachment(s), without copying, saving, forwarding, disclosing or using its contents in any other way. TomTom N.V., TomTom International BV or any other company belonging to the TomTom group of companies will not be liable for damage relating to the communication by e-mail of data, documents or any other information.
> 
> 
> -------------------------------------------------------
> 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_idt77&alloc_id\x16492&op=click
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> 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=7477&alloc_id=16492&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel