Re: [Bluez-devel] REALLY Bad encoding performance of Linux SBC audio codec

["Luiz Augusto von Dentz" <luiz.dentz@gmail.com>]

Hello,

Thanks for doing those tests, we never really have a method for
testing the sbc codec, so PEAQ could be a good start. By looking the
results it seems that our decoder is not really in good shape, which
is not a surprise since we normally only use the encoder part. As for
comparison with the reference implementation, bluez sbc codec does not
use floating point as the reference codec seems to be using, so this
may well be impacting on quality, although we probably gain some
speed.

Other points we might need to consider:
  - Test with different audio source/parameter. (48000hz/mono/28
bitpool is not that common to be used as reference)
  - Mono seems to surfer from quality problems which may cause the problem.
  - Consider working on a gstreamer element for doing live tests based
on ITU BS.1387 (PEAQ)
  - Also consider using liboil as alternative for using floating point.

BTW, don't assume something is bad just because it produces different
results than the reference, as far I can tell you one cannot really
notice _any_ difference between bluez sbc codec and logitech freepulse
e(enhanced)sbc, so on real world we are not that _bad_.

-- =

Luiz Augusto von Dentz
Engenheiro de Computa=E7=E3o

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great priz=
es
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=3D100&url=3D/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel