Vorbis dev - Mar 2009 - vorbisenc creates silent ogg files on ARM EABI

Hi
  Sorry, the reason I joined the list is for help finding a bug that
occurs when libvorbisenc is compiled and run on ARM EABI systems
(current Debian, Gentoo, OpenEmbedded etc).
  The symptom is that oggenc produces shorter ogg files than it should
(about 1/2 size) that decode to the correct duration but of total
silence.

libvorbis/examples/encoder_example does the same on these systems, but
speex (which also uses libogg) is fine and the ogg structure of the
files seems ok, so I'm looking into libvorbisenc.

Here's the Debian bug with gory details: http://bugs.debian.org/515949
which follows on into the xiph tracker https://trac.xiph.org/ticket/1526

It's also compiler and floating-point-implementation dependent:

6456040 Happy.wav
 346624 Happy-x86.ogg (x86, gcc-4.3, correct output)
 186510 Happy-xscale (Debian, armv5te chip, armv4t code, 64-bit
softfloat, gcc-4.3)
 253029 Happy-gcc55 (Gentoo, armv5te chip, armv5t code, 64-bit
softfloat, gcc-4.1.2)
 166377 Happy-gcc-4.1 (Debian, armv5te chip, armv4t code, 64-bit
softfloat, gcc-4.1)

If I compile it to use the MaverickCrunch FPU on the ep9312 armv4t
chip, which doesn't handle denormalized values so floats only have a
precision of 2^-126 instead of 2^-149, I get
   9237 Happy-crunch.ogg (yes, 9k!)

All these ARM .oggs decode to files of the correct length containing
silence and are visible under http://martinwguy/co/uk/martin/libvorbis

Compiling it on a system with a VFP FPU and appropriate flags instead
seems to produce a working encoder.

Following the idea that it's precision-related, I recompiled
-Dfloat=double and got something non-silent and recognizable but
garbled. It sounds like a filtered noise version of the original.
 176372 Happy-armel-encoder_example-double.ogg

I'd like to narrow this down further but am new to vorbis internals,
so my question is: what is the sequence of layers that the sound
passes through during encoding, and are there hooks to be able to
check its integrity at each stage?

Thanks

    M

Martin Guy wrote:
> Hi
>   Sorry, the reason I joined the list is for help finding a bug that
> occurs when libvorbisenc is compiled and run on ARM EABI systems
> (current Debian, Gentoo, OpenEmbedded etc).
>   The symptom is that oggenc produces shorter ogg files than it should
> (about 1/2 size) that decode to the correct duration but of total
> silence.
> 
> libvorbis/examples/encoder_example does the same on these systems, but
> speex (which also uses libogg) is fine and the ogg structure of the
> files seems ok, so I'm looking into libvorbisenc.
> 
> Here's the Debian bug with gory details: http://bugs.debian.org/515949
> which follows on into the xiph tracker https://trac.xiph.org/ticket/1526
Has anyone actually run the (tiny and far from complete) test suite
on one of these platfroms which give weird results?

Unfortunately the test suite is only available in the current SVN
version.

    svn  co http://svn.xiph.org/trunk/vorbis
    cd  vorbis
    ./autogen.sh --disable-docs
    make
    make check

It wouldn't surprise me if the bug you are seeing is a bug that has
been  fixed some time ago in SVN.

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------