mad-dev

mad-dev@lists.mars.org

682 discussions

let the questioning begin
by Sean 'Shaleh' Perry 05 Apr '00

05 Apr '00

So, I see comments to the effect of "need some n-bit type here", "depend on <type> being n-bits", etc. Is there a reason you did not use the int32_t and what not types? They are part of the new C standard, so will be portable. As part of the library API change, it would be nice if library calls were prefixed by some library name, i.e. mad_audio_output(). This way calls for library routines are easily separated from other code. mapplay.c has a function called audio_init(), yet audio_output() is from libmad. This is down right confusing. Seems some functions are defined with the mad_ prefix and others are not. Trying to use 64bit fpm on my pII box causes the CPU load to go up from the average 10% that top shows to around 15%, no noticable sound change. How difficult would it be to add support for external dsp's, like on the sound blaster mp3 cards? I used to own a netwinder, how is the performance on the arm chips?

2 6

'lost synchronization'
by Sean 'Shaleh' Perry 05 Apr '00

05 Apr '00

I get this fairly often when playing an mp3 ends: error: frame 9567: lost synchronization obviously the frame number changes.

2 1

the profiling output
by Sean 'Shaleh' Perry 04 Apr '00

04 Apr '00

Here is the sum'ed output from playing 158 mp3's. My script choked on an mp3 filename, I need to re-work it to continue and play all of my files. But only 29 files were missed, so this is still a rather good sampling. Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 30.03 1223.77 1223.77 1553458 0.79 1.08 mad_synth_frame 25.05 2244.65 1020.88 194672544 0.01 0.01 imdct36 14.27 2826.33 581.68 1553465 0.37 1.46 III_decode 11.12 3279.59 453.26 111848976 0.00 0.00 dct32 7.44 3582.84 303.25 6213849 0.05 0.06 III_huffdecode 3.85 3739.80 156.96 194672544 0.00 0.01 III_imdct_l 2.55 3843.85 104.05 2404546 0.04 0.04 III_stereo 2.31 3937.88 94.03 1553458 0.06 0.06 play 1.96 4017.79 79.91 623683514 0.00 0.00 mad_bit_read 0.72 4047.22 29.43 4170208 0.01 0.01 III_imdct_s 0.13 4052.43 5.21 6213849 0.00 0.00 III_scalefactors 0.13 4057.56 5.13 130319 0.04 0.04 III_reorder 0.08 4060.93 3.37 1682438 0.00 0.00 mad_frame_header 0.08 4064.14 3.21 1682229 0.00 1.36 mad_layer_III 0.07 4067.16 3.02 1682229 0.00 0.01 III_sideinfo 0.04 4068.99 1.82 158 11.52 25792.57 run_sync 0.04 4070.49 1.51 1553458 0.00 0.06 decode_output 0.04 4071.95 1.46 7896185 0.00 0.00 mad_bit_skip 0.02 4072.68 0.72 1682438 0.00 1.37 mad_frame_decode 0.01 4073.28 0.61 1553458 0.00 0.00 mad_timer_add 0.01 4073.82 0.54 284710 0.00 0.00 mad_bit_crc 0.01 4074.26 0.44 1553922 0.00 0.06 audio_oss 0.01 4074.61 0.35 6213849 0.00 0.00 mad_bit_length 0.01 4074.88 0.26 3364159 0.00 0.00 mad_bit_init 0.01 4075.14 0.26 2561981 0.00 0.00 mad_bit_nextbyte 0.00 4075.20 0.07 128805 0.00 0.00 error 0.00 4075.24 0.03 Letext 0.00 4075.26 0.02 128822 0.00 0.00 decode_error 0.00 4075.28 0.02 128805 0.00 0.00 error_str 0.00 4075.28 0.01 Letext 0.00 4075.28 0.00 316 0.00 0.00 decode_input 0.00 4075.28 0.00 316 0.00 0.00 mad_timer_init 0.00 4075.28 0.00 158 0.00 0.00 audio_output 0.00 4075.28 0.00 158 0.00 25792.57 decode 0.00 4075.28 0.00 158 0.00 0.00 mad_decoder_error 0.00 4075.28 0.00 158 0.00 0.00 mad_decoder_filter 0.00 4075.28 0.00 158 0.00 0.00 mad_decoder_finish 0.00 4075.28 0.00 158 0.00 0.00 mad_decoder_init 0.00 4075.28 0.00 158 0.00 0.00 mad_decoder_input 0.00 4075.28 0.00 158 0.00 0.00 mad_decoder_output 0.00 4075.28 0.00 158 0.00 25792.57 mad_decoder_run 0.00 4075.28 0.00 158 0.00 0.00 mad_frame_finish 0.00 4075.28 0.00 158 0.00 0.00 mad_frame_init 0.00 4075.28 0.00 158 0.00 0.00 mad_frame_mute 0.00 4075.28 0.00 158 0.00 0.00 mad_stream_buffer 0.00 4075.28 0.00 158 0.00 0.00 mad_stream_finish 0.00 4075.28 0.00 158 0.00 0.00 mad_stream_init 0.00 4075.28 0.00 158 0.00 0.00 mad_synth_init 0.00 4075.28 0.00 148 0.00 0.00 config 0.00 4075.28 0.00 34 0.00 0.00 mad_stream_sync 0.00 4075.28 0.00 17 0.00 0.00 mad_stream_skip

1 0

in case you want it
by Sean 'Shaleh' Perry 04 Apr '00

04 Apr '00

I compiled mad with profiling and am in the process of running it over my entire mp3 library. I have mp3's encoded w/ bladenc, gogo, and those traded with other people. When finished, I will have 179 profiling outputs. My current findings are (about 2/3's done): Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 31.21 4.26 4.26 5239 0.81 1.10 mad_synth_frame 24.98 7.67 3.41 668256 0.01 0.01 imdct36 16.19 9.88 2.21 5239 0.42 1.43 III_decode 10.84 11.36 1.48 377208 0.00 0.00 dct32 These are consistently the top 4.

3 3

new user, new report
by Sean 'Shaleh' Perry 04 Apr '00

04 Apr '00

Hi all, just grabbed the mad libs today. So far, the sound is as good as mpg123 (at least as far as my ears and speakers are concerned). The CPU usage is about 2 - 3 times that of mpg123 on the same mp3 files. However, mad seems to use a wee less memory. All told, seems like a nice little lib, hope to dig into it more as time goes on. The web page mentions possible API changes, any idea of how soon? How far different?

3 4

MAD 0.10.0b available
by Rob Leslie 19 Mar '00

19 Mar '00

I've released MAD version 0.10.0b: ftp://ftp.mars.org/pub/mpeg/mad-0.10.0b.tar.gz This version contains a better approximation of the high-/low-level API, although the asynchronous high-level API isn't finished. This version also has: SPARC fixed-point math assembly, more documented code, more output modules (raw PCM and hex), and primitive ID3v2 support. Comments and suggestions welcome. -- Robert Leslie rob(a)mars.org

1 0

MAD development directions
by Rob Leslie 13 Mar '00

13 Mar '00

I thought I'd mention some of the development directions I am planning for MAD. These are not in any particular order... 1. I am currently in the midst of adding ID3v2 support to madplay. I've been thinking it might be nice to turn the ID3 tag decoding into a library to go alongside libmad, but I don't have a good interface in mind for this at the moment. 2. The Layer III IMDCT routines (III_imdct_l and III_imdct_s) are slow and absolutely must be rewritten. There are plenty of alternatives, so this is largely a matter of finding the right optimized algorithm and coding it efficiently with integer arithmetic. This will be a priority pretty soon. 3. The API for libmad will be changing slightly. I want to enable two primary interfaces, one high-level and the other low-level. Currently madplay is using the "low-level" interface, where streams, frames, and subband synthesis are all handled explicitly, like this: mad_stream_init(&stream); /* input buffer */ mad_frame_init(&frame); /* individual frames */ mad_synth_init(&synth); /* synthesis output */ /* ... set up input stream ... */ for (each frame) { mad_frame_decode(&frame, &stream); /* frame <- decode(stream) */ mad_synth_frame(&synth, &frame); /* synth <- synthesize(frame) */ /* synth now contains the output PCM samples */ } This interface gives opportunity to modify the frame subband samples before proceeding with synthesis. For example, madplay will transform the frame from stereo to mono if the -m switch is given. Another use would be to apply equalizer or other filters, or to mix two or more MPEG audio streams together with minimal overhead. Every detail must be handled explicitly to use this level of interface; the stream buffer must be updated after input is consumed, and frames with CRC or other errors must be dealt with appropriately. The entire synthesis output must be used before the next frame is synthesized. Another, easier approach from an API perspective might be something like: mad_decoder_init(&decoder); /* contains stream, frame, and synth structs */ /* ... install input, filter, and output modules ... */ mad_decoder_run(&decoder); With this model, the decoder calls the input, filter, and output modules itself to read from the stream, (optionally) filter the subband samples, and finally deliver the PCM output. Another callback could also be used to handle errors, with some appropriate default if no callback has been given. This API might be more desirable for many simple types of applications. It has the added benefit that it could easily be run in a separate thread or process, using some kind of IPC for configuration and control. 4. I am in the process of obtaining a copy of the MPEG 2 standard so libmad can support this in addition to MPEG 1. MPEG 2.5 would also be nice, but I'm uncertain where to find specs as it's not an official standard. 5. It may be possible to improve performance by using 16-bit fixed-point values in some places instead of the current 32-bit ones. This is probably possible without losing quality as long as the output device isn't looking for more than 16 bits of precision. The stumbling blocks I see largely involve the places where values outside the (-1.0, +1.0) range are used, such as for scaling. This is going to be a topic of research. I'd welcome any feedback on these plans, or on madplay or MAD in general... Cheers, -rob

1 0

Jump to page:

2025

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