[Bluez-devel] SBC Decoder Performance

[Bluez-devel] SBC Decoder Performance

[Joe Samuel]

Hi,
While experimenting with the SBC codec, I observed
that the decoder tends to be sluggish as compared with
the encoder (about 20 times). Has anyone noticed this?
Is this behavior expected or did I make some mistake
in my analysis?

Joe


		
___________________________________________________________ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] SBC Decoder Performance

[Brad Midgley]

Joe

yes... the decoder is still doing everything in floating point. it will
be much faster in 64 and eventually 32 bit fixed point. i've been
optimizing it but didn't hit that yet.

brad

> Hi,
> While experimenting with the SBC codec, I observed
> that the decoder tends to be sluggish as compared with
> the encoder (about 20 times). Has anyone noticed this?
> Is this behavior expected or did I make some mistake
> in my analysis?
> 
> Joe
> 
> 
> 		
> ___________________________________________________________ 
> How much free photo storage do you get? Store your holiday 
> snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] SBC Decoder Performance

[Joe Samuel]

Brad,
> the decoder is still doing everything in floating
>point
Yup. I just came to notice that. 
Thank you for the confirmation.

Joe


On 10/18/05, Brad Midgley <bmidgley@xmission.com>
wrote:

    Joe

    yes... the decoder is still doing everything in
floating point. it will
    be much faster in 64 and eventually 32 bit fixed
point. i've been
    optimizing it but didn't hit that yet.

    brad

    > Hi,
    > While experimenting with the SBC codec, I
observed
    > that the decoder tends to be sluggish as
compared with
    > the encoder (about 20 times). Has anyone noticed
this?
    > Is this behavior expected or did I make some
mistake
    > in my analysis?
    >
    > Joe
    >
    >
    >
    >
___________________________________________________________
    > How much free photo storage do you get? Store
your holiday
    > snaps for FREE with Yahoo! Photos
http://uk.photos.yahoo.com
    >
    >
    >
-------------------------------------------------------
    > This SF.Net email is sponsored by:
    > Power Architecture Resource Center: Free
content, downloads, discussions,
    > and more.
http://solutions.newsforge.com/ibmarch.tmpl
    > _______________________________________________
    > Bluez-devel mailing list
    > Bluez-devel@lists.sourceforge.net
    >
https://lists.sourceforge.net/lists/listinfo/bluez-devel



   
-------------------------------------------------------
    This SF.Net email is sponsored by:
    Power Architecture Resource Center: Free content,
downloads, discussions,
    and more.
http://solutions.newsforge.com/ibmarch.tmpl
    _______________________________________________
    Bluez-devel mailing list
    Bluez-devel@lists.sourceforge.net
   
https://lists.sourceforge.net/lists/listinfo/bluez-devel



		
___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] SBC Decoder Performance

[Brad Midgley]

Joe,

Your question did remind me that 4- and 8- subband decoding looked a lot
different in the code (one was unrolled, one wasn't). i got around to
making them look mostly the same so now they're ready for fixed point
changes.

Brad


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] SBC Decoder Performance

[Brad Midgley]

Joe,

(just cleaning out my inbox)

fwiw, we have a fixed-point decoder in the btsco cvs now. If you try it,
let me know how it goes.

Brad

> While experimenting with the SBC codec, I observed
> that the decoder tends to be sluggish as compared with
> the encoder (about 20 times). Has anyone noticed this?
> Is this behavior expected or did I make some mistake
> in my analysis?
> 
> Joe
> 
> 
> 		
> ___________________________________________________________ 
> How much free photo storage do you get? Store your holiday 
> snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] SBC Decoder Performance

[Marcel Holtmann]

Hi Brad,

> fwiw, we have a fixed-point decoder in the btsco cvs now. If you try it,
> let me know how it goes.

is there any need to keep the floating point decoder?

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] SBC Decoder Performance

[Brad Midgley]

Marcel

>>fwiw, we have a fixed-point decoder in the btsco cvs now. If you try it,
>>let me know how it goes.
> 
> is there any need to keep the floating point decoder?

yeah, we should leave it in. The decoder and encoder are written as a
bunch of macro calls that are replaced at compile time by either
floating or fixed point math.

also... floats runs a bit faster if you have an fpu and regression
testing would be easier with a decoder/encoder that we can "trust."

brad


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] SBC Decoder Performance

[Marcel Holtmann]

Hi Brad,

> >>fwiw, we have a fixed-point decoder in the btsco cvs now. If you try it,
> >>let me know how it goes.
> > 
> > is there any need to keep the floating point decoder?
> 
> yeah, we should leave it in. The decoder and encoder are written as a
> bunch of macro calls that are replaced at compile time by either
> floating or fixed point math.

but this is totally ugly.

> also... floats runs a bit faster if you have an fpu and regression
> testing would be easier with a decoder/encoder that we can "trust."

This is no real point. If you need a decoder for regression testing,
then simply make a copy of it.

If the fixed point decoder is too slow, then this needs to be fixed.
Having too decoders won't really help.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] SBC Decoder Performance

[Brad Midgley]

Marcel

>>bunch of macro calls that are replaced at compile time by either
>>floating or fixed point math.
> 
> but this is totally ugly.

the macros are also how the inline arm assembly gets inserted, so there
are potentially a bunch of implementation for each macro, especially
since 32-bit fixed is still experimental:

 - floating
 - 64-bit fixed generic
 - arm 64-bit asm
 - 32-bit fixed generic
 - arm 32-bit asm

it's ugly, but what should it look like? it doesn't look much better by
removing floating from the list.

> This is no real point. If you need a decoder for regression testing,
> then simply make a copy of it.

sure.

> If the fixed point decoder is too slow, then this needs to be fixed.
> Having too decoders won't really help.

inline asm may help but the difference is probably in the noise level.

brad


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] SBC Decoder Performance

[Marcel Holtmann]

Hi Brad,

> >>bunch of macro calls that are replaced at compile time by either
> >>floating or fixed point math.
> > 
> > but this is totally ugly.
> 
> the macros are also how the inline arm assembly gets inserted, so there
> are potentially a bunch of implementation for each macro, especially
> since 32-bit fixed is still experimental:
> 
>  - floating
>  - 64-bit fixed generic
>  - arm 64-bit asm
>  - 32-bit fixed generic
>  - arm 32-bit asm
> 
> it's ugly, but what should it look like? it doesn't look much better by
> removing floating from the list.

I haven't looked through the complete code, but these #ifdef all over
the place are ugly. They should be avoided whenever possible.

> > If the fixed point decoder is too slow, then this needs to be fixed.
> > Having too decoders won't really help.
> 
> inline asm may help but the difference is probably in the noise level.

If possible I would avoid any assembler at all. However it would be at
least something to try.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] SBC Decoder Performance

[Brad Midgley]

Marcel,

> it's ugly, but what should it look like? it doesn't look much better by
> removing floating from the list.

Unfortunately I've been noticing a difference in quality between fixed
and floating. It is subtle, but high-frequency content is harsh and a
little distorted with the fixed point encoder. I could encode some
violin notes if you want to hear the difference.

It would be nice to implement the objective quality measures suggested
by Steven Singer so we could track this down more that's another thing
on the todo list for now.

Brad


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] SBC Decoder Performance

[Marcel Holtmann]

Hi Brad,

> > it's ugly, but what should it look like? it doesn't look much better by
> > removing floating from the list.
> 
> Unfortunately I've been noticing a difference in quality between fixed
> and floating. It is subtle, but high-frequency content is harsh and a
> little distorted with the fixed point encoder. I could encode some
> violin notes if you want to hear the difference.

no need to. I believe you if you say so. Anyhow I still think that there
is no need to keep a floating point encoder/decoder.

> It would be nice to implement the objective quality measures suggested
> by Steven Singer so we could track this down more that's another thing
> on the todo list for now.

Keep up the good work.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel