hissing background noise with mp3 sounds (with workaround/fix)

[andras@…]

gcc 3.3.1 miscompiles mp3lib on i386. This results in a relatively silent noise
when playing such.
My first workaround was to specify "-ac mad,", which made the noise go away.
Further investigation showed that adding "-fno-strict-aliasing" to the OPTFLAGS
in the mp3lib/Makefile really fixed the problem.
This might also be the cure for the OPTFLAG setting to -O0 on ppc, as -O0 also
disables strict aliasing.
Affected is both 1.0pre5 and current MPlayer dev-CVS-040917-06:00-3.3.1,
CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 0,
compiled for MMX MMX2 3DNow 3DNowEx SSE

Ari

[reimar]

(In reply to comment #0)

This might also be the cure for the OPTFLAG setting to -O0 on ppc, as -O0 also
disables strict aliasing.

Wrong, the only fix is using a working compiler! This is _not_!!! an MPlayer
bug! Report it to the gcc team, they broke it!

[andras@…]

Technically you are right - it's a gcc bug.

This doesn't help anyone however, as it should be your intend to deliver
a working product. Unfortunately gcc 3.3.x is the standard compiler for most
current distributions, so I bet lots of people are hit by that.
Additionally it's you who calls for the problem by specifying -O4...

The work around is simple and won't hurt anybody. Just check for the compiler
version and specify the damn -fno-strict-aliasing option if required, and
everyone will be happy with a good mplayer. More mature people, like for
example kernel developers, took that step in the best interest of their users
long ago.

So, if you insist on your childish position "Mam, it's not my fault! They did
it!", go ahead playing in the sandbox. This perfectly matches the mplayer
developers reputation.

[reimar]

(In reply to comment #2)

Technically you are right - it's a gcc bug.

Actually, I have to admit, it seems I was not. Not completely at least, as the
mp3lib code doesn't conform to aliasing rules. Unless somebody intends to
fix/improve mp3lib (without making it slower), adding -fno-strict-aliasing would
be acceptable, but it must not change code produced by gcc 2.95.
This makes it a bit more work so it will take some time.
In the meanwhile you could e.g. use -ac ffmp3.

Nevertheless I have to comment on the rest of your reply. It's just my personal
opinion, but I think quite a few other developers will agree more or less.

This doesn't help anyone however, as it should be your intend to deliver
a working product. [...]

Well, but it actually is not my intend. And I'd really like to know why it
should be, I'm working on this in my freetime, for fun, after all!

Additionally it's you who calls for the problem by specifying -O4...

I know about people that complained about MPlayer being too slow when compiled
with -O2 instead, so maybe you have a computer where -O2 is acceptable, but some
haven't.

The work around is simple and won't hurt anybody. Just check for the compiler
version and specify the damn -fno-strict-aliasing option if required, and
everyone will be happy with a good mplayer. More mature people, like for
example kernel developers, took that step in the best interest of their users
long ago.

If the workaround is so simple, you are free to write a patch. But I won't touch
configure when I can avoid it (which you will have to do for the version check).
And I can think of a lot more reasons why kernel developers work around compiler
bugs while we usually don't:
1) The kernel is system critical, MPlayer is not, although some people think so ;-)
2) They have quite few assembler code, so they just don't experience most gcc
3.x bugs
3) Compiling the kernel with -O2 is much more acceptable performance-wise than
it is for MPlayer, avoiding you another big share of compiler bugs
4) Quite a few kernel developers are paid and have no choice.
5) connected with 4): They have far more resources. Do you know how many
developers are currently active in the MPlayer project? Do you know how long the
TODO list of some of these is? There are lots of patches that nobody has had
time to review and are thus not included in MPlayer, although they provide a
useful feature. Which isn't the case for compiler workarounds, as you can either
use gcc 2.95, some other working compiler version or binary packages (decreasing
the probability of us helping you with bugs, but still...) if you want...

So, if you insist on your childish position "Mam, it's not my fault! They did
it!", go ahead playing in the sandbox. This perfectly matches the mplayer
developers reputation.

I don't know which reputation you mean exactly, but I at least doubt that
MPlayer would have as many features as it has now if developers had spend their
time on compiler "würgarounds" instead of implementing features. So think about
the possibility that we have good reasons to do things the way we do before
calling us "childish"

[reimar]

avoid aliasing rules for mp3lib and libmpeg2