mad-dev October 2000

mad-dev@lists.mars.org

7 participants
10 discussions

Why libmad is compiled with -O1
by Andre 30 Oct '00

30 Oct '00

I don't remember who it was, but someone was asking about why libmad is compiled with -O1 optimisation (instead of eg -O3). Anyway, I just found the results of some profiling tests I did a while back using the Pentium Time Stamp Counter to profile the imdct36() function in layer3.c, mad-0.11.0b. Hopefully the results are of interest, although I can't really offer too much explanation except to suspect 'features' in the gcc optimiser.... All results are in clock cycles on a Pentium III: gcc version egcs-2.91.66 (ie stock RH 6.2): gcc -O1 : 1329 clocks (asm mad_f_mul), 1529 clocks (C mad_f_mul) gcc -O2 : 1607 clocks (asm mad_f_mul), 2176 clocks (C mad_f_mul) gcc -O3 : 1608 clocks (asm mad_f_mul), 2186 clocks (C mad_f_mul) gcc version 2.95.2 19991024: gcc -O0 : 2946 clocks (asm mad_f_mul), 2616 clocks (C mad_f_mul) gcc -O1 : 1735 clocks (asm mad_f_mul), 1201 clocks (C mad_f_mul) gcc -O2 : 1380 clocks (asm mad_f_mul), 1567 clocks (C mad_f_mul) gcc -O3 : 1380 clocks (asm mad_f_mul), 1567 clocks (C mad_f_mul) Rob, any news on an ETA for the next release ?? Andre -- ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie

4 5

MAD plug-in for Winamp
by Rob Leslie 30 Oct '00

30 Oct '00

All, I've completed a beta version of a MAD plug-in for Winamp. You can download it from the MAD home page: http://www.mars.org/home/rob/proj/mpeg/ It currently lacks streaming support, but will handle all *.MP[123] files. One of the goals of the plug-in is to provide 24- and 32-bit output if your soundcard supports it. However, it is not known whether any Winamp output plug-ins (including the Nullsoft waveOut plug-in) support any resolution greater than 16 bits. I don't have the necessary hardware to test this, so I'm hoping to get feedback from anyone who can try it. I will be releasing source for the plug-in along with the next regular source code release. Cheers, -rob

1 0

Re: [mad-dev] Why libmad is compiled with -O1
by Andre 25 Oct '00

25 Oct '00

--- Nicolas Pitre <nico(a)cam.org> wrote: > > On Wed, 25 Oct 2000, Andre wrote: > > > All results are in clock cycles on a Pentium III: > > > > gcc version egcs-2.91.66 (ie stock RH 6.2): > > > > gcc -O1 : 1329 clocks (asm mad_f_mul), 1529 clocks (C mad_f_mul) > > gcc -O2 : 1607 clocks (asm mad_f_mul), 2176 clocks (C mad_f_mul) > > gcc -O3 : 1608 clocks (asm mad_f_mul), 2186 clocks (C mad_f_mul) > > > > gcc version 2.95.2 19991024: > > > > gcc -O0 : 2946 clocks (asm mad_f_mul), 2616 clocks (C mad_f_mul) > > gcc -O1 : 1735 clocks (asm mad_f_mul), 1201 clocks (C mad_f_mul) > > gcc -O2 : 1380 clocks (asm mad_f_mul), 1567 clocks (C mad_f_mul) > > gcc -O3 : 1380 clocks (asm mad_f_mul), 1567 clocks (C mad_f_mul) > > This is strange. > > The gcc-2.95.2 results are somewhat different on a StrongARM. They > are more inline with the egcs-2.91.66 results above... > In terms of clock cycles, I would expect a (single issue) StrongARM to require a lot more than a (super-scalar) Pentium III for a given C function. Unfortunately though, I don't have a suitable ARM platform to do any gcc testing with, so haven't been able to test this. I have a copy of ARM's 'Armulator' simulator which gives very good profiling information, but only runs code compiled with ARM's C compiler. Unfortunately, ARM's C compiler makes such a bad job of 64bit data types that I don't think any MAD benchmarks generated this way are very useful as a guide to how fast the code would run when compiled with gcc. I do have an ARM Integrator board (ARM720T cpu), which I guess should be able to run Linux, but I haven't yet investigated the effort required to get it to do so.... Out of interest, the imdct36() part of my ARM assembler imdct36 + windowing function requires just under 1100 clock cycles on the simulator. So with a bit of assembler tweaking, a humble StrongARM can be faster than a Pentium III :-) Andre -- ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie

1 0

Requantisation optimisations.
by Andre 16 Oct '00

16 Oct '00

Rob + others, Attached is my latest effort at re-quantisation (+ other minor) optimisations for mad-0.11.4b. This patch supersedes all my previous patches for 0.11.4b (ie it also includes the imdct_s optimisation). Compared with an untouched 0.11.4b, on an AMD K6 I get: - Approx 4.1 % speed increase (MHz for realtime decode decreases from 45.7 to 43.8) when configured with --enable-accuracy. - Approx 9.4 % speed increase (MHz for realtime decode decreases from 34.8 to 31.5) when configured with --enable-speed. - Accuracy increases slightly. Andre -- ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie

1 0

Update
by Rob Leslie 13 Oct '00

13 Oct '00

There are a number of things worth mentioning about MAD of late. First, I have set up a SourceForge project which I plan to use for the public forums, bug manager, support manager, and patch manager, as well as to mirror the distributions. I may also use it for the task manager, although this is less clear to me at the moment. You are welcome to continue submitting patches on this mailing list, although you might prefer to post them on SourceForge instead (and follow-up with a note here) since there is no public archive for this list. I may also set up CVS on SourceForge at some point, if people are interested. The SourceForge project page is: http://sourceforge.net/projects/mad/ In other news, I have made some rather drastic changes to MAD which I plan to release soon as 0.12.0b. These changes include: Throughout: - use of automake - use of libtool (to simplify building shared libraries) libmad: - extended the timer API, making it very useful - the async API is almost finished - extended the decoder API to enable (fast) header decoding and an opportunity to preempt decoding the rest of the frame - numerous other API changes madplay: - support for long-style options - support for internationalization (via GNU gettext) - support for start/stop playing in the middle of a file - support for shuffle/repeat - modularized filter framework - new fade-in filter to start with (fade-out, inter-song gap, and cross-fade handling planned) Besides finishing up the above, I'm also currently trying to decide how best to deal with mpg123 compatibility. This is important because it will allow MAD to be used as the back-end decoder for many existing front-end GUIs. Tom Lawler has contributed a modified version of madplay that will emulate mpg123 output, enough to provide minimal functionality to work with gqmpeg. This apparently all runs quite well on the iPaq. :-) His package can be found here: ftp://handhelds.org/pub/apps/sound/ I'd like to incorporate something like this into the primary distribution, but I would like to do a more complete emulation, including support for all or most of mpg123's command-line options. Unfortunately, I think to do this right will cause the size of madplay to bloat too much, so I'm considering making this a separate program ("mad123") that just uses the MAD library. Is there anyone interested in working on this? I can do it, but I'd rather spend time finishing other things... Also speaking of sub-projects, since the next release of MAD will be internationalized, would anyone here with non-English speaking skills like to contribute translation(s)? Finally, since I've been working largely on the above, I haven't had a chance to incorporate some of the more recent patches, particularly Andre's imdct_s and requantization optimizations. I haven't rejected them, but they will probably have to wait until 0.12.1b. That's all for now. Cheers, -rob

1 0

No float point supported
by warmice 04 Oct '00

04 Oct '00

Hi,Andre: We want to port mad to a little system built up by ourselves . We use our own CPU ,controlers, complilers etc. Our CPU isn't so powerful yet so it cannot support floating point yet. So mad is perfect for our project . :-)

1 0

Re: [mad-dev] compile mad in VC
by Andre McCurdy 03 Oct '00

03 Oct '00

--- Zhang Tao <warmice(a)sina.com> wrote: > Hi, > Can someone tell me how to change the following statement so it > can be compliled in VC++? > > # define mad_f_mul(x, y) \ > ({ mad_fixed64hi_t __hi; \ > mad_fixed64lo_t __lo; \ > asm ("imull %3" \ > : "=a" (__lo), "=d" (__hi) \ > : "%a" (x), "rm" (y)); \ > mad_f_scale64(__hi, __lo); \ > }) > There are 2 main reasons why this will not compile with VC++. Firstly because it is a 'statement expression' (a gcc specific thing which I don't think exists in VC++), and secondly because it uses the gcc syntax for including inline assembler. The easiest way to get things working is to use FPM_64BIT rather than FPM_INTEL which will cause mad_f_mul to be defined as a regular macro, and not use any inline assembler. What platform are you planning to run the compiled code on ? If its PC, then maybe one of the floating point mp3 decoders might be a better choice than mad ?? Andre -- ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie

1 0

compile mad in VC
by Zhang Tao 03 Oct '00

03 Oct '00

Hi, Can someone tell me how to change the following statement so it can be compliled in VC++? # define mad_f_mul(x, y) \ ({ mad_fixed64hi_t __hi; \ mad_fixed64lo_t __lo; \ asm ("imull %3" \ : "=a" (__lo), "=d" (__hi) \ : "%a" (x), "rm" (y)); \ mad_f_scale64(__hi, __lo); \ }) Many thanks.

1 0

RE: [mad-dev] question about mmap
by David Van Brink 02 Oct '00

02 Oct '00

Warmice: > But I want to port mad to a simple system so there is no such complex > function call available.My question is how can I write someting to replace > mmap function call. That's exactly what we just did, ran mad on a little OS-less embedded system. To redundantly restate what Rob said: mmap() makes it *seem* as if the whole mp3 file has been read into an array. Reading it into an array yourself will do the same thing, and that's how we first got mad running (with rather short mp3 songs to fit in our 256k of RAM :-). Below is the main loop that we used instead of, more or less, the "decode()" routine in madplay.c. The routine that's called below, "WOSFS_Read()" is a simple file-read call. (But it sounds like the current version of mad will do this for you already...) -- David Van Brink /* * * nios_mp3_getNextFrame() fills up the nios_mp3.synth * with one frame's worth of data, or returns an error. */ int nios_mp3_getNextFrame(nios_mp3 *nm) { int result = 0; result = mad_frame_decode(&nm->frame,&nm->stream); // // the decode may fail due to a lack of source data, // in which case we'll read some and try again // if(result == -1 && (nm->stream.error == MAD_ERR_BUFLEN || nm->stream.error == MAD_ERR_BUFPTR)) { long tailSave; // how much is still good in the buffer long size = kFileBufferSize; // amount we'll try to have on-hand if(nm->currentFilePosition >= nm->fileLength) { result = -1; goto goHome; } tailSave = nm->stream.bufend - nm->stream.next_frame; size -= tailSave; #if NIOS_MP3_DEBUG printf("nios_mp3_getNextFrame: size = %d, tailSave = %d\n",size,tailSave); #endif // Copy the tail to the head // memmove(nm->fileBuffer,nm->fileBuffer + nm->currentBufferSize - tailSave,tailSave); // Clamp size to fileLength // if(nm->currentFilePosition + size > nm->fileLength) size = nm->fileLength - nm->currentFilePosition; // Read in the new bytes // WOSFS_Read(nm->fileNumber,nm->currentFilePosition,size,nm->fileBuffer + tailSave); nm->currentBufferSize = size + tailSave; nm->currentFilePosition += size; // Give new buffer to the stream // mad_stream_buffer(&nm->stream, nm->fileBuffer, nm->currentBufferSize); // And try that frame decode again (but no more after this!) // result = mad_frame_decode(&nm->frame,&nm->stream); } if(result && nm->stream.error != 1) // "error" 1 is normal file-end printf("nios_mp3_getNextFrame: mad_frame_decode returned %d/%d\n", result,nm->stream.error); if(result == -1) goto goHome; nm->framesDecoded++; mad_synth_frame(&nm->synth,&nm->frame); nm->samplesGenerated += nm->synth.pcmlen; goHome: return result; } -----Original Message----- From: Rob Leslie [mailto:rob@mars.org] Sent: Sunday, October 01, 2000 9:00 AM To: warmice Cc: mad-dev(a)lists.mars.org Subject: Re: [mad-dev] question about mmap > The function mmap(....) appears several times in madplay.c and minimad.c > .I don't know what the function will exactly do ,bu I think it's related > with paging ? The function maps the file into the memory address space of the process. The file can then be accessed directly with memory references rather than by calling read(). This is helpful because it enables random access without worries about buffering, as this is done in the kernel -- the file is paged into memory only as needed. It also eliminates copying data from the kernel's buffer into user space. > But I want to port mad to a simple system so there is no such complex > function call available.My question is how can I write someting to replace > mmap function call. I don't know if Windows provides a similar capability. However, `madplay' has been written to work without it. Just don't define HAVE_MMAP. > Can I just allocate a mem buffer and read the file to the buffer and using > the pointer to buffer as void * fdm in the main()? I try it but it seems to > cause some error.When I decode to the almost end of a mp3 file ,it will > sometimes report 0x0101 error. > > /* fdm = mmap(0, stat.st_size, PROT_READ, MAP_SHARED, STDIN_FILENO, 0);*/ > fdm = malloc(stat.st_size); > inputstream = fdopen(STDIN_FILENO,"r"); > fread(fdm,sizeof(char),stat.st_size,inputstream); This will probably work, although it is perhaps a bit greedy to read the entire file into memory at once. You might prefer to read the file in chunks, as `madplay' will do when HAVE_MMAP is not defined. The 0x0101 error means MAD lost synchronization with the bitstream. I have found this to be common if the file contains an ID3v1 tag at the end of the file; the tag is apparently not always located at a frame boundary. I will try to work around this, but for now you can ignore the error. -- Rob Leslie rob(a)mars.org

1 0

question about mmap
by warmice 01 Oct '00

01 Oct '00

Hi,everyone: The function mmap(....) appears several times in madplay.c and minimad.c .I don't know what the function will exactly do ,bu I think it's related with paging ? But I want to port mad to a simple system so there is no such complex function call available.My question is how can I write someting to replace mmap function call. Can I just allocate a mem buffer and read the file to the buffer and using the pointer to buffer as void * fdm in the main()? I try it but it seems to cause some error.When I decode to the almost end of a mp3 file ,it will sometimes report 0x0101 error. /* fdm = mmap(0, stat.st_size, PROT_READ, MAP_SHARED, STDIN_FILENO, 0);*/ fdm = malloc(stat.st_size); inputstream = fdopen(STDIN_FILENO,"r"); fread(fdm,sizeof(char),stat.st_size,inputstream); Can someone give me some help? Many many thanks.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

mad-dev October 2000