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

[Reza Naima]

Rob Leslie wrote:

> 
> In order for minimad to use mmap(), it's necessary to invoke it like this:
> 
>     minimad <input.mp3 >output.pcm
> 

That's how I did invoke it, before the change.  It still failed. 
Perhaps because the location of the mp3 file is nfs mounted, though 
that's just a guess.


> 
> 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?
> 


To test this, I went ahead and forced madplay to little-endian :

/*
# if defined(WORDS_BIGENDIAN)
#  define audio_pcm_s32  audio_pcm_s32be
#  define audio_pcm_s24  audio_pcm_s24be
#  define audio_pcm_s16  audio_pcm_s16be
# else
*/
#  define audio_pcm_s32  audio_pcm_s32le
#  define audio_pcm_s24  audio_pcm_s24le
#  define audio_pcm_s16  audio_pcm_s16le

//# endif


It played the audio just fine.  Perhaps it has something to do with 
minimad's scale() function (I'm currently using it as-is, in my code)? 
I might try ripping out some of the audio massaging code from 
audio_raw.c and putting into my code to see what it does.  Otherwise, do 
you have any other thoughts?


One other question -- with the high-level API's call of 
mad_stream_buffer(), does it want data in a prefered size?  Or does it 
have to end on some multiple of some size?

Thanks,
Reza