I have libmad running on a 940T at 160MHz. It uses about 35% of the CPU
decoding a 128kbps/44100Hz stereo MP3, so you should have no problem if
your system isn't doing much else. RAM and flash won't be an issue for
you, either.
I don't use madplay any more, but it isn't resource-hungry.
Sorry, can't help with the second part.
> -----Original Message-----
> From: mad-dev-admin(a)lists.mars.org
> [mailto:mad-dev-admin@lists.mars.org]On Behalf Of Andrew Douglas
> Sent: 27 …
[View More]January 2005 21:35
> To: mad-dev(a)lists.mars.org
> Subject: [mad-dev] PCM output to DAC
>
>
> Hi
>
> I'm currently developing on an Altera Excalibur EPXA1db board, which
> has an arm922T running at 200 MHz, 32 MB ram and 8 MB flash. I've got
> a Linux 2.4 kernel running on the board with a basic root filesystem.
> I'm looking at cross-compiling madplay (& libmad) to run on this
> architecture and would appreiciate a bit of advice before starting.
>
> 1. Does the system I'm using appear to have enough resources to be
> able to run this application. Does anyone have figures for MIPS,
> memory requirements and CPU usage for this application running on a
> similar ARM architecture? My system has no hardware FPU but does have
> an MMU.
>
> 2. I require the decoded stream to be sent, via general purpose IO
> pins, to a customised PCB with a (16-bit) DAC and audio preamp. I plan
> to use the folowing command:
>
> $ ./madplay --output=raw:/dev/dsp foo.mp3
>
> Will I have to write a device driver to enable this or is there a
> simple way to direct the stream to the memory mapped pins?
>
> Is there anything else that I overlooked? Any help would be
> appreiciated.
>
> TIA
>
> Andy Douglas
>
The contents of this email and any attachments are sent for the personal attention
of the addressee(s) only and may be confidential. If you are not the intended
addressee, any use, disclosure or copying of this email and any attachments is
unauthorised - please notify the sender by return and delete the message. Any
representations or commitments expressed in this email are subject to contract.
ntl Group Limited
[View Less]
Hi
I'm currently developing on an Altera Excalibur EPXA1db board, which
has an arm922T running at 200 MHz, 32 MB ram and 8 MB flash. I've got
a Linux 2.4 kernel running on the board with a basic root filesystem.
I'm looking at cross-compiling madplay (& libmad) to run on this
architecture and would appreiciate a bit of advice before starting.
1. Does the system I'm using appear to have enough resources to be
able to run this application. Does anyone have figures for MIPS,
memory …
[View More]requirements and CPU usage for this application running on a
similar ARM architecture? My system has no hardware FPU but does have
an MMU.
2. I require the decoded stream to be sent, via general purpose IO
pins, to a customised PCB with a (16-bit) DAC and audio preamp. I plan
to use the folowing command:
$ ./madplay --output=raw:/dev/dsp foo.mp3
Will I have to write a device driver to enable this or is there a
simple way to direct the stream to the memory mapped pins?
Is there anything else that I overlooked? Any help would be appreiciated.
TIA
Andy Douglas
[View Less]
Hi,
Has anybody been successful in porting MAD to symbian
series 60??
Please, if you have any ideas worth sharing...
Thanks
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail
After built libmad, I still don't get mad.h file.
I've been read the README file, it said : "The API for
libmad can be found in the `mad.h' header file. Note
that this file is automatically generated, and will
not exist until after you have built the library."
So?? How to generate mad.h??
Thanks
__________________________________
Do you Yahoo!?
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250
I accidentally loaded some non-audio data in my application, and I'm
getting:
a.out: layer3.c:2640: mad_layer_III: Assertion `stream->md_len + md_len - si.main_data_begin <= (511 + 2048 + 8)' failed.
I'm using the low-level interface. I can reproduce this with madlld,
if I change INPUT_BUFFER_SIZE from 5*8192 to 4*8192 or lower (my own
buffer is 16k).
The file (edited down as small as I can get it while still triggering
this) is at:
http://zewt.org/~glenn/testfile
There's …
[View More]some MPEG-1 video in there, which I suppose MAD is picking up;
that's fine, I just want it to gracefully play garbage or give a fatal
error, without dying.
--
Glenn Maynard
[View Less]