mad-dev

mad-dev@lists.mars.org

682 discussions

more profiling
by Sean 'Shaleh' Perry 25 Apr '00

25 Apr '00

So, I was running the profiler and seeing what the slow points were. To help me see it better I split out a chunk of III_decode into III_decode_a. This chunk is the sizable portion from the first for loop. Now profiler output is better broken down: 29.81 5.72 5.72 7394 0.77 1.05 mad_synth_frame 20.43 9.64 3.92 768704 0.01 0.01 imdct36 10.84 11.72 2.08 532368 0.00 0.00 dct32 8.49 13.35 1.63 29576 0.06 0.12 III_decode_a 7.76 14.84 1.49 29576 0.05 0.06 III_huffdecode 7.14 16.21 1.37 7394 0.19 1.53 III_decode 6.88 17.53 1.32 177728 0.01 0.01 III_imdct_s 3.49 18.20 0.67 768704 0.00 0.01 III_imdct_l 2.50 18.68 0.48 14788 0.03 0.03 III_stereo 1.62 18.99 0.31 2919640 0.00 0.00 mad_bit_read Where III_decode() used to weigh in at 2, it is now seen as 3 chunks. I doubt this patch is of any worth, but I just wanted to share. in dct32() there is a cos table declared every single call, why not move this to just before the function? in III_huffdecode() you make a new block for most of the function call. Why use this temporary block?

2 2

MAD 0.10.1b available
by Rob Leslie 23 Apr '00

23 Apr '00

I made a new snapshot of MAD, version 0.10.1b. ftp://ftp.mars.org/pub/mpeg/ I managed to create three new optimizations for this version to significantly improve performance across all layers and use less memory at the same time. On the StrongARM 1100, performance for Layer III improved from 37% to 31%. Layer II improved from 22% to 17%, and Layer I from 23% to 18%. This puts MAD ahead of all known integer decoders for Layer I and Layer II, and only behind Xaudio (at 24%) for Layer III. For a more complete summary, see the TIMINGS file in the distribution. The specific optimizations I made were to observe that the least significant 12 bits in all the subband synthesis windowing coefficients were zero, so the multiplication cycle count could be reduced on some machines by pre-shifting these away to create greater leading-zero or leading-one counts. The second optimization I made was to reduce the windowing coefficient table almost in half (saving memory) by utilizing symmetry, and simultaneously localizing the symmetric computation such that fewer overall memory references are needed. The third optimization was to modify the way fixed-point multiplication is performed during synthesis windowing, in conjunction with the first optimization. Since the coefficients have only 16 significant fractional bits, multiplying by a 12-fractional-bit number would yield exactly 28 fractional bits. Thus all the fixed-point shifts can be eliminated during windowing if the input is pre-shifted by 16 (28-12) bits. Another benefit of this optimization is the compiler can more easily choose to use a multiply-accumulate instruction if one is available. This last optimization loses precision in the output, but I think this should not generally be audible. I haven't yet analyzed the loss with respect to decoding compliance, although this is my intention. If anyone is interested in looking into this, I'd appreciate the help. The optimization can optionally be turned off to get more accurate output. I still have not yet rewritten the Layer III IMDCT, so Layer III performance will get better still. How much? The lower bound can be seen in the Layer I and Layer II numbers, since these are the simplest layers that use the same subband synthesis. This version also has some code cleanup, including fixed_t -> mad_fixed_t renaming as suggested, new M/S and intensity stereo indicators for madplay's verbose mode, and plenty of other miscellaneous changes. There is also new sample code `minimad.c' which shows perhaps the simplest use of the libmad API. Cheers, -rob

1 0

subband synthesis and dct32() explained
by Rob Leslie 08 Apr '00

08 Apr '00

The output of the decoding process, from any layer, is a set of subband samples. There are 32 subbands which cover the entire frequency spectrum. In Layer I, each decoded frame contains 12 complete sets of 32 subband samples which, after synthesis, will become 384 PCM samples. In both Layer II and Layer III, each frame contains 36 sets of 32 subband samples which, after synthesis, will become 1152 PCM samples. Each channel is independent at this point, so there are separate sets of subband samples for each channel. Subband synthesis is the process of transforming the subband samples, which are in the frequency domain, into PCM samples, in the time domain. The MPEG audio standard defines a process for doing this, although the algorithm presented in the standard is extremely inefficient to implement as it stands. The algorithm involves a 1024-value block made up of 16 individual 64-value vectors. A single 64-value vector is generated from a complete set of 32 subband samples via something resembling a Discrete Cosine Transformation (DCT). This transformation is what the matrix multiply in synth.c is all about. It turns out that due to trigonometric symmetry, it is only necessary to calculate half of the 32->64 transformation. The relationship between the two halves is spelled out in this comment in the code: x[i] = x'[i + 16] i = 0..15 x[i + 17] = -x'[31 - i] i = 0..15 x[i + 32] = -x'[16 - i] i = 0..15 x[i + 48] = -x'[i] i = 0..15 x[16] = 0 where x[] is the 64-value output vector recognized in the standard, and x'[] is the output of a 32-point DCT of the 32-value input vector. dct32() is merely an optimized implementation of a 32-point DCT based on Lee's fast DCT algorithm (also sometimes credited to Hou.) For the details of this, I recommend reading: http://flux.fe.uni-lj.si/%7Earpi/stuff/fastdct.pdf http://developer.intel.com/drg/mmx/appnotes/ap533.htm Now, rather than expand the output of the 32-point DCT into a vector of 64, it is more efficient to leave them alone and simply take into account the necessary changes in sign (seen above) later on in the calculations. According to the standard, each computed 64-value vector is supposed to be shifted into the 1024-value block, shifting out the oldest 64-value vector from the block. A circular buffer is used for this in MAD rather than shuffling memory around. Also, it's only half as big since we're storing 32 values instead of 64. The 32 values are also split in half because of the way the PCM samples are constructed, into a lo half and a hi half. In the code, the whole block is synth->filterout[channel][half][index] where the index ranges 0..255 over the total set of 16 vectors for either half. Finally, this value block is windowed and PCM samples are constructed. The standard defines 512 windowing coefficients, found in the file D.dat. Due to the way values are shifted into the block, each windowing pass covers alternating halves of each vector in the block. This is where the lo and hi sets come from, denoted with evenp and oddp pointers during the windowing and PCM reconstruction. This obviously isn't a complete description, but it should probably help in navigating synth.c. If anyone would like more details, please ask. -rob

1 0

long long patch
by Sean 'Shaleh' Perry 06 Apr '00

06 Apr '00

Enclosed is the diff to remove 'long long' from the code. I used diff -c, most people like it. If you prefer a different format, please let me know. Now for the decisions. You use shorts, longs and ints throughout the code. On alphas, a long is 64 bits. I suspect the same will happen on 64 bit sparc and I know it has happened on the ia64. It is not always documented how many bits a specific value is expected to hold and I do not understand the code well enough yet to make the decisions. The items to use are [u]int16_t, [u]int32_t, and [u]int64_t. If you want to be uniform there is also [u]int8_t (char).

2 2

cmpiling on sparc64
by Sean 'Shaleh' Perry 05 Apr '00

05 Apr '00

I have a sparc64 I can compile on over the net, but I do not have the luxury of hearing if my hacking works or not. The configure script does not properly detect the architecure, it enables the approximation code, if I pass it fpm=sparc all is well.

2 3

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

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