I confirm. The mp3 sound becamy floppy and high and low frequencies are distorted weirdly. (Mids are bearable though)

Have this problem been seen by anyone outside Debian installation?

I'm not using Debian (using Gentoo instead), and its a hand-built KDE from CVS (as of two days).

Okay. Since the difference is between 3.2.1 and 3.2.2, there is an off-chance it is related to the changes that happend in ALSA. 

What aRts driver are you using?
And does the problem occur if you install an older aRts with a newer KDE (and mpeglib)?

-> comment #4
- debian arts package version is 1.2.2-1
- I have to test that last question of you.
 - Do you mean _older_ or _newer_ mpeglib by "(and mpeglib)"?
 - Do mean "mpeglib" or "libarts1-mpeglib" by "mpeglib"?

I mean a newer mpeglib as it is part of kde-multimedia, and with mpeglib I mean both libarts1-mpeglib and mpeglib in Debian terms.

I basically wants to narrow down if bug happens in newer aRts or mpeglib, and testing with mixed versions could do it.

apt doesn't seem to give me the possibility to downgrade the arts package. But take a look at the link to the debian list I mentioned in my original bug report. There somebody solved the problem by downgrading mpeglib and libarts1-mpeglib.

Or could somebody else (Stanislav ?) make the downgrade test of his arts package if still necessary?

I tried with both latest CVS HEAD arts and latest ARTS_1_1_BRANCH with new mpeglib/mpeglib_artsplug, the problem seems to persist.
I'll test more in the evening.
(Been playing for two hours with it yesterday, funnily mpeglib changes are mostly memleaks cleanup between KDE_3_2_1_RELEASE and HEAD)

Btw, I'm using alsa output with 2.6.5 kernel. It was all nice until recent kde upgrade.
I also have an mp3 file that perfectly reproduces the problem, so i'm using it for testing.

same here since (approx.) March 17 (kde_branch, self-compiled).

kernel: 2.6.5 / 2.6.6-rc2

regards,
muesli

*** Bug 80581 has been marked as a duplicate of this bug. ***

Hi there,

I don't know, if you need this information anymore, but I have proof, that it's the mpeglib or the mpeglib-plugin that makes the trouble. I downgraded both packages in debian from unstable (version 3.2.2) to testing (version 3.1.5) but left the newer arts. since then everything is ok. Also, if I deinstall the mpeglib plugin, then arts sucks CPU as hell (perhaps one could remove this bad performance code from arts or inherit the mpeglib code completely?) but plays mp3 nicely.

Greetz,
HD

I should note that this bug is NOT related in any way to ALSA. I am using arts with OSS output, and I still get the problem. I also did not get the problem before installing the 3.2.2 libarts1-mpeglib package, though I did get 50-75% CPU utilization when using arts for ANYTHING. Downgreading to the 3.1.5 libarts1-mpeglib and mpeglib Debian packages solves the problem.

I think we've narrowed to problem to be in mpeglib or mpeglib_artsplug.

The only problem I see is that there are _no_ commits that could look too suspicious within this month.

But! To me, reverting to kdemm from KDE_3_2_1_RELEASE does NOT fix the problem, so it might've been introduced earlier.

I have narrowed the problem even further.
Building latest HEAD kdemm/mpeglib with "-O0" helps to prevent those nasty "quips" and "gulps". I would have to analyze generated machine code to find where gcc borks, but I'll leave it to our assembly gurus, don't feel like doing it atm.

berkus: thanks for all your work :-)

I spotted the file responsible for bug: its
mpeglib/lib/splay/mpeglayer3.cpp
Compiling it with optimizations other than -O0 causes things to break.

I can't confirm. HEAD CVS dated 20040510, g++ 3.3.3 compiled with -O2 -march=athlon-tbird -mmmx -m3dnow.

I'm listening to an MP3 on JuK, playing through aRts and through ALSA (Linux kernel 2.6.6). No distortions that I can hear.

Can you check if you have other optimisations enabled (-march especially).

Same here.

I compiled my system (Gentoo, KDE 3.2.2) with some agressive CFLAGS
(march=athlon-mp, -O3 etc.pp.). The same bug here on my system!

I recompiled kdemultimedia with _only_ -O0, and now it works. :-)

Florian: can you try rebuilding kdemultimedia/mpeglib with -O2 -march=athlon-tbird and see if it produces faulty code?

Ok, I'm going to test it.
But you have to wait... I'll build it on sunday evening, not enough time to do it right now :-(

Regards!

I finally managed to reproduce too with CVS-HEAD and my usual optimizations ("-O2 -march=athlon -ffast-math").

It is not very noticiable here. It only happens on some numbers and only on the bass where some kind of "flopping" bass sound appears.

Thiago, maybe you have a the bug too on a similarly difficult-to-detect level?

I can also confirm that compiling lib/splay/mpeglayer3.cpp without optimizations solves the problem. Compiling it with just the -O1 optimization introduces it again. I've been unable to trace it to any specific optimization enabled by O1 (disabling them doesnt help).

I am guessing the bug is introduced by the distos moving to gcc-3.3 from gcc-3.2 rather than the move from KDE 3.2.1 to KDE 3.2.2, since mpeglayer3.cpp haven't been changed since 1999.

Allan, that's what makes the bug so hard to spot. The distortion isn't noticable for a lot of songs... Then you suddenly find a song that its really noticable on.

As I said, I have a perfect test case: K-PAX OST - Grand Central. At 1:04 into the song where percussions start - the distortion is quite heavy.

I'm looking into what may be causing this misoptimization now.

Compiling splay/mpeglayer3.cpp with g++-3.2 removes the problem as well. 

Now to figure out if it is a gcc-3.3 or old mpeglib bug..

I am using "Yes, You Can" from Jewel - 0304. It starts with some good bass, so I can tell if it is working within the first 5 seconds of the song.

http://berk.upnet.ru/files/80497-testcase.mp3 (6Mb)
my testcase
please link to yours, i can provide webspace if you need
i will cut the sample down when i get my audacity to work =)

CVS commit by karchebny: 

* Fix that nasty misoptimization bug.

* Would anyone mind if I clean up these Augean stables, or is it better to just drop mpeglib altogether? .)

CCMAIL: 80497-done@bugs.kde.org


  M +2 -2      mpeglayer3.cpp   1.6


--- kdemultimedia/mpeglib/lib/splay/mpeglayer3.cpp  #1.5:1.6
@@ -907,6 +907,6 @@ void Mpegtoraw::layer3dequantizesample(i
 
         do{
-          out[0][index]=factor*TO_FOUR_THIRDS[in[0][index++]];
-          out[0][index]=factor*TO_FOUR_THIRDS[in[0][index++]];
+          out[0][index]=factor*TO_FOUR_THIRDS[in[0][index]];index++;
+          out[0][index]=factor*TO_FOUR_THIRDS[in[0][index]];index++;
         }while(--count);
       }

*** Bug 81676 has been marked as a duplicate of this bug. ***

Stanislav: I have a plugin that can playback ogg/flac/mp3/wav effectively 
obsoleting mpeglib for all it is currently used for. I plan to add it to kdemultimedia before KDE 3.3, so dont waste too much time on it.

Great, then I'm not going to waste time on this mess.

Allan: Does your plugin implement streaming? You cannot obsolete mpeglib for mp3 without implementing the streaming interface, that would be a regression.

For those who can't wait for a fixed version of the Debian mpeglib package I found this link. The package is built with -o0.
http://www.marm.org.uk/mpeglib_3.2.2-1_i386.deb

Recompiling arts and kdemultimedia with -O0 fixed the problem.

> Recompiling arts and kdemultimedia with -O0 fixed the problem. 
 
Do you people ever read?

*** Bug 80976 has been marked as a duplicate of this bug. ***