[mad-dev] mad on arm processor -- strange problems.

[Rob Leslie]

On Sunday, May 26, 2002, at 04:32  PM, Reza Naima wrote:
> Seems there's a problem with the high-level API..
>
> First off, the mmap() function in madplay was failing for some reason. So 
> I added an open() and used that filedescriptor rather than the stdio's fd.

In order for minimad to use mmap(), it's necessary to invoke it like this:

     minimad <input.mp3 >output.pcm

>   Running it generated this error, which is what I also see when I try to 
> use the high-level API with my code :
>
> minimad > /tmp/r
> decoding error 0x0101 (lost synchronization) at byte offset 0

This is not an unusual error if the file contains an ID3v2 tag or 
otherwise does not immediately begin with MPEG audio data.

> I modified minimad again, this time to ignore that error.  The output is 
> identical to what I heard when I was doing the decoding with my 
> application.
>
> However, I also tried using madplay (raw output format), and it worked 
> great.  Audio sounded perfect.  So, what do you think the problem  could 
> be with the high level API?

I don't think the problem is with the high-level API since both minimad 
and madplay use it.

Perhaps the problem is the byte order of the output samples. minimad 
always outputs little-endian samples, but madplay's raw output uses the 
native endian format of your host. Is your audio driver expecting 
big-endian samples?

--
Rob Leslie
rob@mars.org