[Tremor] Byte order problem

[Monty]

On Wed, Sep 22, 2004 at 08:21:38AM +0200, Niklas Barsk wrote:
> Hi,
> 
> I tried using ntohs and ntohl on the buffer from ov_read() but it does
> not do anything with its content. I have not found any good examples
> of how to use ntohl so I might use it the wrong way. This is what I
> tried to do right after the ov_read() (buf contains the read data):
> 
> {
> int i;
> for( i = 0; i < buflen; ++i)
>  buf[i] = htonl( buf[i] );
> }

If you're on Sun, that operation is a no-op.  

> > I had also problem with endienness. What I have find is that the
> > definition in misc.h is used only for the computation. It don't change the
> > endienness of the output. You can use ntohs (network to host short)or
> > ntohl (network to host long)to revert the output regerated end it will
> > give you the good result.

No.  That converts 'network' (big endian) to host.  Tremor's
output is already host endian.

> > > I am running the lowmem branch of Tremor on a Sun Solaris workstation.
> > > There were some problems compiling the misc.h file, both endian
> > > versions of the union magic was compiled and caused a conflict. 

That's only a missing define.

> > > With this modification the code compiles but the output file just
> > > contains noise. I tried to run Tremor on another Linux computer and
> > > that gives a good output. I have decoded the same Vorbis file on both
> > > systems and compared them with a hex editor. The difference is that  the
> > > Sun decoded file has a somewhat different byte order than the Linux.
> > > When the Linux version has the order A B C D the Sun version has B A D
> > > C.

Right.  Sun is big endian.  Linux on PC is little endian.  The output
is thus correct for both, as documented.

> > > Does anyone know why this happens and how I can solve it?

You decode wass correct.  It's what you're doing with the data
afterward that's likely erroneous.

Monty