Dear Maintainer,

TL;DR: it seems that libmad is not really usable on s390x.

i'm currently trying to find out why sonic-visualiser_3.0.3-1 fails to build
successfully on the s390x and arm64 architectures.
The problem is a failing test when decoding mp3 files.
The test runs fine on most release architectures, but fails on
- arm64
- s390x
- alpha
- hppa
- m68k
- sh4

Now while trying to hunt this down, i think i found an issue with libmad.
Using the following test-program:

    #!/usr/bin/env python

    import mad
    mf = mad.MadFile("sine.mp3")
    data = mf.read()

    offset = 2048
    print([_ for _ in data[offset:(offset+1024)]])


and the attached minimal MP3-file "sine.mp3" i get different results for s390x
(zelenka.debian.org) and amd64 (my laptop):

s390x = [  0,   1,   0,   1, 255, 254, 255, 254, 255, 252, 255, 252, 0, 5, ...
amd64 = [252, 255, 252, 255, 254, 255, 254, 255,   0,   0,   0,   0, 1, 0, ...

I've also ran the file through the 'minimad' example that comes with libmad
(sources), and the output differs on the two architectures (i've attached the
results as 's390x.bin' resp.  'amd64.bin').
i haven't done any checks on architectures that are supposed to be "ok"
(according to my test-suite).

Would it be possible to fix this?
If not, should the failing architectures be marked as "not-for-us"?

mgfasdr
IOhannes

Hi,

2017-11-09 17:23 IOhannes m zmoelnig:

Not the maintainer here, and not specially interested in this package
per se, but the last upload was an NMU made by me to fix multi-arch
issues, so chiming in just in case...

I am not sure if my upload has anything to do with it, sonic-visualiser
seems to have failed before that.

To see if they have anything in common, let's investigate a bit:

64-bit little-endian

64-bit big-endian

64-bit little-endian

32-bit big-endian

32-bit big-endian

32-bit little-endian


... so they don't have much in common in that respect.

I would be tempted to update to the latest upstream version, but the
last release was in 2004 :(

Since I never worked with this library before or know anything about the
field, I am not sure if I can do much more in this respect.


Cheers.

AC_MSG_CHECKING(for architecture-specific fixed-point math routines)
AC_ARG_ENABLE(fpm, AC_HELP_STRING([--enable-fpm=ARCH],
                   [use ARCH-specific fixed-point math routines
                    (one of: intel, arm, mips, sparc, ppc, 64bit, default)]),
[
    case "$enableval" in
        yes)                             ;;
        no|default|approx) FPM="DEFAULT" ;;
        intel|i?86)        FPM="INTEL"   ;;
        arm)               FPM="ARM"     ;;
        mips)              FPM="MIPS"    ;;
        sparc)             FPM="SPARC"   ;;
        ppc|powerpc)       FPM="PPC"     ;;
        64bit)             FPM="64BIT"   ;;
        float)             FPM="FLOAT"   ;;
        *)
            AC_MSG_RESULT(failed)
            AC_MSG_ERROR([bad --enable-fpm option])
            ;;
    esac
])

if test -z "$FPM" && test "$GCC" = yes
then
    case "$host" in
        i?86-*)     FPM="INTEL"  ;;
        x86_64*)    FPM="64BIT"  ;;
        arm*-*)     FPM="ARM"    ;;
        mips*-*)    FPM="MIPS"   ;;
        sparc*-*)   FPM="SPARC"  ;;
        powerpc*-*) FPM="PPC"    ;;
        # FIXME: need to test for 64-bit long long...
    esac
fi

AC_MSG_RESULT(${FPM=DEFAULT})

if test "$FPM" = "DEFAULT"
then
    AC_MSG_WARN([default fixed-point math will yield limited accuracy])
fi

You should probably set it to 64BIT, which is what I did for amd64.
The others are assembler implementations.


Kurt

[...]

So I want to clarify this a little. Is the reason for failing that
the results are not identical, but still produce an output that contains
a sine, just a little bit different?

Since this is a fixed point implementation, and you have a build
that's limited to 32 bit, it's sort of expected that it doesn't
produce the same results, and it's clearly a tradeoff between
quality and speed. And I'm not sure which is prefered on some of
those architectures.


Kurt