xmms-cdread produces white noise with the equalizer on (even if doing nothing) due to endianess problems on big endians machines (or at least my big endian machine - an iBook 800 CDROM) Reproducible: Always Steps to Reproduce: 1. Play a CD with the specified plugin (on a big endian machine) 2. Turn the equalizer on (even if with the default values) 3. Wait a few seconds for the buffer to end Actual Results: You get plain white noise: "txxxxxx" Expected Results: Play the tune equalized A patch that solves me the problem (please someone else try it out): diff -Naur xmms-cdread-0.14a/filter.c xmms-cdread-0.14a-endian/filter.c --- xmms-cdread-0.14a/filter.c 2001-04-09 19:33:13.000000000 +0100 +++ xmms-cdread-0.14a-endian/filter.c 2003-10-01 22:16:45.000000000 +0100 @@ -37,9 +37,17 @@ int i, j, k; sample *data = buf; real ol, or; + char *p; + + int little_endian = 1; + little_endian = *(char *)&little_endian; if (!cd_eq_on) return; + if (!little_endian) for (p = (char *)data; p < (char *)(data + len); p += 2) { + p[0] ^= p[1] ^= p[0] ^= p[1]; + } + for (i = 0; i < len; i++) { ol = fc[0] * (real)data[i].l; or = fc[0] * (real)data[i].r; @@ -58,6 +66,11 @@ data[i].l = (short)ol; data[i].r = (short)or; } + + if (!little_endian) for (p = (char *)data; p < (char *)(data + len); p += 2) { + p[0] ^= p[1] ^= p[0] ^= p[1]; + } + } #define PI 3.1415926535897932384626433832795029L My "emerge info" as requested (not that I think it really necessary in this case): Portage 2.0.49-r3 (default-ppc-1.4, gcc-3.2.3, glibc-2.3.2-r1, 2.4.21-ppc-r2) ================================================================= System uname: 2.4.21-ppc-r2 ppc ACCEPT_KEYWORDS="ppc" AUTOCLEAN="yes" CFLAGS="-Os -fforce-addr -ffast-math -frename-registers -fsigned-char - mcpu=750 -pipe" CHOST="powerpc-unknown-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/confi g /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-Os -fforce-addr -ffast-math -frename-registers -fsigned-char - mcpu=750 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="ccache" GENTOO_MIRRORS="http://darkstar.ist.utl.pt/gentoo ftp://ftp.rnl.ist.utl.pt/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://ftp.rnl.ist.utl.pt/gentoo-portage" USE="oss libwww jpeg nls gif sdl png ppc gdbm berkdb slang readline java gpm tcpd pam ssl perl python esd imlib opengl X gtk gtk2 ncurses tiff zlib xmms - alsa -dvd -xv -mitshm -oggvorbis -gnome -qt -kde -motif -mozilla -truetype - cups -foomaticdb"
Hey... anybody? I'd like to ear from the package mantainer, if there's any chance of this getting to the tree. Anyone knows how I could find him? (I thought this was supposed to be the vehicle, am I wrong?) Or comments from just about from anyone else: if you have the problem, tell me if it works for you, and if you don't tell me if it messes anything.
here xmms-cdread is happly segfaulting and before adding your patch I'd rather find our why that happens, btw why just not use an #IFDEF __BIG_ENDIAN instead of a runtime check? Hopefully I'll add your patch in the weekend
Well, I've tried that... But unfortunaly that seems disrupted too. I have an Apple iBook 800, which is obviously working in big endian mode, but since PowerPC's can also work in big endian mode, GCC leaves these flags to be defined further down the row, and then seams to fall back to some "default" little endian defines. I've been intending to submit this as a bug in endian.h, but I still haven't...
Well, since I compiled in a new version of GCC a few days ago, I was curious if the endian.h situation was still an issue and it turns out it isn't any more. Maybe I did something wrong the other time... but well.. doesn't matter it works now! Here is an uptated version of the patch: diff -Naur xmms-cdread-0.14a/filter.c xmms-cdread-0.14a-endian/filter.c --- xmms-cdread-0.14a/filter.c 2001-04-09 19:33:13.000000000 +0100 +++ xmms-cdread-0.14a-endian/filter.c 2003-10-17 22:57:34.000000000 +0100 @@ -4,6 +4,7 @@ #include <stdio.h> #include <string.h> #include <math.h> +#include <endian.h> typedef double real; @@ -37,9 +38,16 @@ int i, j, k; sample *data = buf; real ol, or; + char *p; if (!cd_eq_on) return; +#ifdef __BIG_ENDIAN + for (p = (char *)data; p < (char *)(data + len); p += 2) { + p[0] ^= p[1] ^= p[0] ^= p[1]; + } +#endif + for (i = 0; i < len; i++) { ol = fc[0] * (real)data[i].l; or = fc[0] * (real)data[i].r; @@ -58,6 +66,13 @@ data[i].l = (short)ol; data[i].r = (short)or; } + +#ifdef __BIG_ENDIAN + for (p = (char *)data; p < (char *)(data + len); p += 2) { + p[0] ^= p[1] ^= p[0] ^= p[1]; + } +#endif + } #define PI 3.1415926535897932384626433832795029L
committing your patch, still xmms itself provides the same features that this plugin does. Sorry for the delay
Well, this bug is still there, today. Using xmms-1.2.10-r5, xmms-cdread-0.14a-r1 and EQ enabled on Pentium 4 leads to this bug. xmms-cdread is the only way to hear to CDDA-Tracks when using supermount (instead of HAL/DBUS/GNOME-VOLUME-MANAGER or IVMAN), because libcd leads to more glitches.
