On 2015-05-25 14:57, Arun Raghavan wrote:
On 25 May 2015 at 12:49, hwang4 <hui.w...@canonical.com> wrote:
On 2015年05月25日 14:40, David Henningsson wrote:
On 2015-05-25 06:49, Hui Wang wrote:
On 32bits OS, this test case fails. The reason is when rewinding to
the middle of a block, some of float parameters in the saved_state
are stored in the memory from FPU registers, and those parameters will
be used for next time to process data with lfe. Here if FPU register
is over 32bits, the storing from FPU register to memory will introduce
some variation, and this small variation will introduce small
variation to the rewinding result.
Very interesting finding. I didn't know that storing things back and forth
to memory could change the computation result.
And the fact that it only happens on 32-bit platforms and only with
optimisations makes it even stranger. Makes me wonder if this is actually an
gcc optimisation bug.
Probably.
Did I misunderstand something here? Fixing a problem with the compiler
in our test seems to be incorrect.
My assumption is that as long as we have -ffast-math on, then these are
things we have to live with (and thus calling it a "gcc optimisation
bug" is inaccurate, sorry about that).
Being pragmatic: since the difference is one bit only, no one will hear
any difference. But if you feel like digging into it further, I'm
curious to know the result. :-)
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
