Upstream's guess was not an endianess bug, but rather subtle differences in floating point math (gbsplay unfortunately has not yet been rewritten to use fixed point calculations).
After finally getting a MIPS system running under QEMU (with Debian
Etch, I can't find any newer installation instructions), I can confirm
this: I built gbsplay under mips, generated the example file, swapped
it's endianess and listened to it on my normal system.
Everything sounded normal.
mipsi:~/gbsplay-0.0.92# ./gbsplay -c examples/gbsplayrc_sample -o oss \
examples/nightmode.gbs 1 < /dev/null > stdout
# ... copy to host system ...
mitch@zecora:~$ sox -B -r48000 -e signed -b32 stdout.BE.raw -L stdout.LE.raw
mitch@zecora:~$ mplayer -rawaudio channels=2:rate=48000:samplesize=2 \
-demuxer rawaudio stdout.LE.raw
# sound fine =b
So the "solution" to this bug will be to disable the tests on the
affected architectures. We don't have the resources to generate
proper hashes on all architectures on every code change that affects
the output.
As I've just now realized, gbsplay-0.0.91-1 had the tests completely
disabled for every architecture, so this solution is no drawback
compared to older package versions :-)
Regards
Christian
--
....Christian.Garbs.....................................http://www.cgarbs.de
Es gibt badische Mensche und es gibt unsymbadische Mensche.
signature.asc
Description: Digital signature
