Hi!

Further on in the file it's still not OK. With the same sourcecode and MP3 data the PC (with Visual C++) is doing OK from the beginning.

I haven't took al look at the GCC compiler. I go to Germany for a few days for my work, so I continue on this problem next week.

Thanks for all the tips.

Jeroen

----- Original Message ----- From: "Andre" armccurdy@yahoo.co.uk To: "Jeroen T" jeroen_t@hotmail.com; mad-dev@lists.mars.org Sent: Monday, February 18, 2002 8:24 PM Subject: Re: [mad-dev] Problems when porting to MIPS processor using Greenhills compiler

Jeroen T jeroen_t@hotmail.com wrote:

...

Hi.

I tried everything. Make all memory zero which is allocated. use calloc instead of malloc, change to FPM_64BIT and back to FPM_DEFAULT. Changing optimization. Everytime I get the same picture. Nothing helps...

Did you try looking at the waveform in the middle of the file ? ie is the strange modulation only at the start (first few frames) of the decoded output, or all the way through ??

...

Somebody knows a free MIPS VR4111 C compiler?

Yes, gcc !!!

You could build your own, but to save hassle I would recommend that you try one of the precompiled versions available for MIPS. I've personally used the version available from http://www.algor.co.uk although its certainly not the only choice.

Beware that the assembler and object file formats used by gcc may not be the same as those used by ghs, so combining a gcc compiled version of libmad with your existing ghs compiled C runtime environment (startup files, RTOS etc) may not be entirely straightforward... :-)

Andre

---

Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com

Gareth,

I am trying to get the mad decoder working on the Sharp ARM Evaluator board.

That wouldn't be the AEB1 board with an ARM7DI cpu (ie lacking the enhanced 32x32bit multiply instructions) and a 24 MHz cpu clock would it ??

If so, be aware that you should configure MAD with FPM_DEFAULT, and the fact that you stand no hope at all of listening to any decoded output in real time... :-)

The way i see it, i need to alter minimad so that it takes a pointer to where the start of the mp3 file is, and then another pointer for where it should start writng the pcm samples.

Yes. Remember to update your pointers every time you copy data out of or into your buffers so you know where to read/write on the next call and you should be laughing. (Even so, its probably best to get this far on a PC before going near the ARM board).

Good luck.

Andre --

__________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com

"G.C.Bransby" wrote:

I'm not certain about the board but i know it has an ARM7TDMI. The board has written on it : ARM EVALUATION BOARD ASSY : HBI-0041C Will this ARM be able to decode mp3s in real time? No great loss if it won't, this is just a learning exercise :-)

As an indication a 233MHz SA-110 (ARM9ish??) uses about 30% cpu when decoding 192kb/s mp3s in realtime.

Simon. -- Simon Burge simonb@wasabisystems.com NetBSD CDs, Support and Service: http://www.wasabisystems.com/

OK, this may be a really dumb question but here goes anyway. If i compile libmad in linux using the normal ./configure, make, make install routine, will i be able to use the resulting library for development on a windows machine?

On Thursday, February 21, 2002, at 01:59 PM, Gareth wrote:

I have been playing with minimad for a while now but need some explanations for a few things ;-) The comments say that standard input is mapped into memory using mmap(). So :

Is mmap a C builtin function?

mmap() is a POSIX function; it is implemented as a system call on nearly all operating systems having a UNIX-like kernel.

What do the arguments mean, especially 'stat.st_size'? fdm is the pointer to where the mp3 has been mapped into memory, right?

From the Linux mmap(2) man page:

SYNOPSIS #include <unistd.h> #include <sys/mman.h>

caddr_t mmap(void *start, size_t length, int prot , int flags, int fd, off_t offset);

int munmap(void *start, size_t length);

DESCRIPTION The mmap function asks to map length bytes starting at offset offset from the file (or other object) specified by fd into memory, preferably at address start. This latter address is a hint only, and is usually specified as 0. The actual place where the object is mapped is returned by mmap. The prot argument describes the desired memory pro- tection. It has bits

PROT_EXEC Pages may be executed.

PROT_READ Pages may be read.

PROT_WRITE Pages may be written.

PROT_NONE Pages may not be accessed.

The flags parameter specifies the type of the mapped object, mapping options and whether modifications made to the mapped copy of the page are private to the process or are to be shared with other references. It has bits

MAP_FIXED Do not select a different address than the one specified. If the specified address cannot be used, mmap will fail. If MAP_FIXED is speci- fied, start must be a multiple of the pagesize. Use of this option is discouraged.

MAP_SHARED Share this mapping with all other processes that map this object

MAP_PRIVATE Create a private copy-on-write mapping.

You must specify exactly one of MAP_SHARED and MAP_PRI- VATE.

FYI, stat.st_size is simply the size of the file in bytes as it exists in the filesystem. Thus, the entire file is mapped.

-- Rob Leslie rob@mars.org

On Thursday, February 21, 2002, at 04:20 PM, john cooper wrote:

Realistically, mmap() is a luxury provided by virtual memory operating systems. As used my minimad it is a simple way to get the system to do the file I/O automatically under the hood, and simplifies the programming model. You will however find doing the stream I/O yourself to be lower overhead and more appropriate for the application environments where libmad is attractive.

Granted, without a virtual memory system, mmap() might not be the best or even a possible approach. However, it can have special benefits when available that make it more attractive than traditional I/O. Since mmap() usually provides direct access to memory pages from the filesystem's block cache, the overhead of additional private buffer space and memory copying is avoided. Eliminating the buffer for your own stream I/O can be important especially in low-memory environments, particularly since multiple instances can share memory-mapped pages.

On systems where the secondary data storage is already memory-accessible, such as flash devices, mmap() is an even more obvious choice.

-- Rob Leslie rob@mars.org

john cooper wrote:

What I was getting at was if hardware FP isn't around I'd predict an MMU won't be either.

I'd tend to disagree with this, especially in the higher-end embedded market (ie anything based on a modern RISC core). There's quite a few MIPS and PowerPC based CPUs around that don't have FP but do have fully functioning MMUs. Now, as to whether or not your operating environment provides mmap() (and it's efficency if it does) is a different question :-)

Simon. -- Simon Burge simonb@wasabisystems.com NetBSD CDs, Support and Service: http://www.wasabisystems.com/