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ção ------------------------------------------------------------------------- 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 prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Bluez-devel mailing list Bluez-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/bluez-devel
