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