Phil Leigh;289459 Wrote: > I'm thinking it's that the error was not a rounding error in the 24th > bit, but actually "rounding errors" happening much higher up....say at > the 16th bit or even higher...that was caused by the maths involved in > the volume control stepping.
Sorry Phil - I never responded to this. Certainly it's possible that there was at some point a bug that prevented the firmware from rounding properly, and if so the error could be arbitrarily large. But if you round correctly (and we're just talking about multiplying two numbers, it's not rocket science) the error due to the rounding is always in the LSB of the bit depth you're using. The procedure slimserver was using before the "bug" fix - at least as described in the bug report I linked to - is proper rounding when multiplying by a gain factor that isn't a divisor of 256. What had changed was that the new volume curve meant that -none- of the gain factors (other than max, of course) were divisors of 256, so at any volume setting there was a rounding error. But as we've seen, that error is totally negligible. After the "bug" fix all of the gain factors down to -30dB or something divided 256, so there was no longer any roundoff error, but the volume scale wasn't quite linear in dB any more. Neither of those is audible, so it doesn't matter - the whole thing was a waste of time. -- opaqueice ------------------------------------------------------------------------ opaqueice's Profile: http://forums.slimdevices.com/member.php?userid=4234 View this thread: http://forums.slimdevices.com/showthread.php?t=45736 _______________________________________________ audiophiles mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/audiophiles
