2012/3/26 Siarhei Siamashka <siarhei.siamashka@xxxxxxxxx>: > On Sun, Mar 25, 2012 at 5:51 AM, qduaty <qduaty@xxxxxxxxx> wrote: > Out of curiosity, how do you measure noise reduction? It seems to reduce noise making it less audible. I didn't perform objective measurements because it's not relevant as long as the (decoded) stream is not used for encoding. > Floating point code does not need any rounding coefficient. You have right, I missed the comment. t1 should be initialized to 0. > I find it hard to believe that this accumError would make any > noticeable difference on the output (neither good nor bad). I don't believe it either, but it is a trick. Perhaps my results are biased, but it always seems that adding 0.5 before rounding adds some noise, while adding accumError calculated this way, does the opposite (removes some noise). Objective measurements could give the right answer. Anyway, if you're interested in the patch, I'd be careful with removing the part of code involving accumError - it's computationally cheap and at least one listener claims it improves quality. Three "blind" listeners could give you meaningful statistical data. > With your change, you are only messing around the lowest bit in the extra > fractional part. Now I'm surprised that it actually works. > If you have any questions about the current code, just ask. How to call sbc_encode(), sbc_decode() and again sbc_encode() in a single function? It seems they cannot use the same instance of sbc_t struct. I tried to estimate the amount of attenuation for adaptive clipping prevention (obviously this solution is suboptimal but can be a good starting point). Regards -- Sebastian Olter -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
