mad-dev

mad-dev@lists.mars.org

682 discussions

Re: [mad-dev] MAD 0.11.2b available
by Andre McCurdy 16 Sep '00

16 Sep '00

Nicolas, Well done for spotting the ARM 'Round while you shift' optimisation ! Originally in imdct_l_arm.S, I made a fairly arbitrary choice to round in some places and just shift in others to try and balance code-size/speed against accuracy. With your optimisation its possible to round everywhere with no penalty, so I guess it makes sense to do so. I've attached a new version to this email which hopefully should be the most accurate version so far - it now rounds everywhere like FPM_ARM and FPM_64BIT, but has the advantage over them of using 64bit accumulators for the imdct part. Rob, Just a small tweak: if ASO_IMDCT is defined, the window_l[] table in layer3.c doesn't need to be included (at a saving of 144 bytes....) as imdct_l_arm.S already contains its own copy. 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

2 1

MAD 0.11.2b available
by Rob Leslie 15 Sep '00

15 Sep '00

I put a new release of MAD on the FTP site. It's a day later than promised, but I wanted to incorporate some patches Nicolas sent me. This version has many changes. The highlights are: libmad changes: * Incorporated Nicolas Pitre's ARM assembly and parameterized scaling changes. * Incorporated Andre McCurdy's ARM assembly optimization (used only if --enable-aso is given to `configure' to enable architecture-specific optimizations.) * Reduced FPM_INTEL assembly to two instructions. * Fixed accuracy problems with certain FPM modes in synth.c. * Improved the accuracy of FPM_APPROX. * Improved the accuracy of SSO. * Added experimental rules for generating a libmad.so shared library. madplay changes: * PCM output is now dithered for better audio quality. * Added a resampling feature for unsupported output sampling frequencies. * Improved the OSS output module by falling back on 8-bit format if 16-bit is not available, and by using native 16-bit endianness. * Added a dual channel output selection option. The ARM changes produced a favorable effect on the accuracy of the output from libmad on ARM processors; ARM output is no longer the same as Intel output and instead now matches the 64bit output, but with better performance: default with SSO with ASO with SSO+ASO FPM_APPROX 6.800e-05/L 6.775e-05/L 6.431e-05/L 6.431e-05/L FPM_64BIT 5.580e-08/F 1.007e-05/L 5.652e-08/F 1.008e-05/L FPM_ARM 5.580e-08/F 1.007e-05/L 5.652e-08/F 1.008e-05/L FPM_INTEL 9.000e-08/F 1.008e-05/L /F means full compliance, /L means limited accuracy, /N means not compliant. Perhaps the most significant change to `madplay' is the addition of PCM output dithering. This is an alternative to ordinary rounding that improves the audio quality by reducing the negative effects of quantization noise. Dithering is commonly used in professional mastering when reducing studio-quality audio to 16 bits for pressing onto a CD. Since MAD produces PCM samples with >24 bits, dithering is a good idea. The dithered output sounds less "grainy" than non-dithered, although this is easier to perceive with 8-bit output than with 16. Best of all, however, dithering effectively increases the precision of the output because it allows bits below the LSB to be heard. There are many possible dithering strategies, but the chosen algorithm is fairly simple: it merely involves keeping the cumulative quantization error less than the significance of the LSB. The effect of this is for the LSB to modulate in proportional agreement with the bits below it. The only significant drawback with dithering is that it hinders an analytic examination of the output, such as compliance testing. Therefore, it can be turned off with a -d option to `madplay'. As always, the release can be found here: ftp://ftp.mars.org/pub/mpeg/ Cheers, -rob

1 0

Re: [mad-dev] MPEG audio decoder compliance
by Andre McCurdy 12 Sep '00

12 Sep '00

Rob, Interesting. If you have them, I would also be interested in figures for MAD which compare multiplies using FPM_64BIT, a version which truncates the LSBit (eg FPM_ARM), and FPM_APPROX. Thanks 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

3 2

MPEG audio decoder compliance
by Rob Leslie 18 Aug '00

18 Aug '00

I thought people might be interested in some results I'm putting together of tests for MPEG audio decoder accuracy. These are the same tests I wrote about some time ago, but now I have results for a much wider range of decoders, and across all three layers. MAD is still showing well, and is in fact the only decoder I am aware that will produce 24-bit output. The results are interesting: http://www.mars.org/home/rob/proj/mpeg/compliance/ Worth noting is that MAD is the only decoder in the class of integer decoders that can produce fully compliant output. Does anyone have any suggestions for decoders to test that are not listed? I would like to test the ARM decoder somehow, but I don't know if I can get access to it. Cheers, -rob

1 0

Layer3 III_imdct_l() in ARM Assembler.
by Andre McCurdy 16 Aug '00

16 Aug '00

Rob + others, Please find attached a version of the layer3 III_imdct_l() function I've written in ARM assembler. I've been messing around with it for a while, mainly as an exercise to learn ARM assembler, but hopefully the end result is worth sharing. Performance wise, it should be quite a bit faster than the current C version (and slightly more accurate as well since the multiply-accumulate steps accumulate into 64bits, then round back to 32bits only when finished). Unfortunately, I don't actually have any ARM based hardware that will play audio, so its only been tested standalone with a small range of test cases on the 'armulator' ARM simulator. Any feedback (especially overall performance) or bug reports from anyone actually able to test it for real would be appreciated. It assembles for me (using gcc v2.95.2) with just: arm-elf-gcc -c arm_III_imdct_l.S (making sure that the extension is .S rather then .s to cause gcc to run it though the C pre-processor). I'd appreciate some feedback, even if the performance increase isn't big enough to bother including it in future releases. 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

2 1

MAD 0.11.1b available
by Rob Leslie 04 Aug '00

04 Aug '00

I made a new release of MAD (0.11.1b) with the following changes: - the libmad code is now in a separate directory - the robustness of the Win32 audio output module is much improved - the SSO is now disabled by default, as output accuracy is deemed to be more important than speed in the general case - a bug in the Layer III sanity checking was fixed that could have caused a crash on certain random data input - the Layer III requantization table was extended from 8191 to 8206 values as some encoders are known to use these values, even though ISO/IEC 11172-3 suggests the maximum should be 8191 (and I couldn't convince anyone on the LAME mailing list that this could be a bug in LAME) - a short man page for madplay was added - a new `madtime' program (not yet built or installed by default) accurately calculates average bitrate and playing time for any file, including VBR - a new experimental multi-stream mixer `madmix' was added (--enable-experimental during configure to add -x option support for this to madplay) The experimental mixer code is designed to minimize CPU involvement in decoding multiple bitstreams; subband synthesis is performed only once after all the mixing has taken place on the intermediate decoded data. Here's an example usage: madmix <(madplay -Qx one.mp3) <(madplay -Qx two.mp3) Any number of input streams can be given on the command line to be mixed. You can also use the same -o option as for `madplay'. If your shell doesn't support process substitution with named pipes, you'll have to mess around and make them yourself. Currently the mix is fixed at 100% for all streams, but this can be adjusted on line 330 of madmix.c. I think there's potential for command-line or file-based configuration to further make this useful, or possibly even a GUI. As always, the release can be found here: ftp://ftp.mars.org/pub/mpeg/ Cheers, -rob

1 0

Re: [mad-dev] Optimisations in layer3.c
by Andre McCurdy 29 Jun '00

29 Jun '00

> Have you compared your optimised version of 0.10.0b to what's > now in 0.11.0b ? > I'm curious what your benchmarking will reveal.. when I get a > chance I'm definitely going to take a closer look at it. I just compared the 0.11.0b version of imdct36() with mine: gcc -O1 : 1329 clocks (asm mul_f), 1529 (C mul_f) gcc -O2 : 1607 clocks (asm mul_f), 2176 (C mul_f) gcc -O3 : 1608 clocks (asm mul_f), 2186 (C mul_f) All of which beat my best of 2215 clocks. It could be closer on an embedded processor with a smaller cache though. The raw output isn't identical to the older version, but i guess this is just different rounding errors (?). My x86 assembler knowledge isn't to good so I haven't really looked at why gcc seems to be so much worse with optimisations above -O1. As well as being slower, code size almost doubles e.g. 10448 bytes (-O3) against 5391 (-O1) for the latest imdct36() using a C mul_f, so maybe its a problem with optimisation in my version of gcc (the default egcs-2.91.66 installed with RH6.2) Does arm-elf-gcc behave in the same way ?? > > On a different subject, does anyone have access to an ARM platform > > for testing ?? I would be interested to know how the MAD code > > (with and without my changes) compares to ARM's own mp3 decode > > library (which claims to use only 29 MHz of cpu bandwidth for real > > time decode on an ARM7 core). > > I have access to a StrongARM 1100 and a 110, but not to anything > else. I don't think I have access to ARM's MP3 decoding library, so > I can't do any comparisons against it. However, I can evaluate your > improvements to MAD alone on the StrongARM. ARM's MP3 decode library (see http://www.arm.com/SoftSys/as022.html ) isn't available for free so it might be difficult to get hold of a copy, but if the claims are true (ie 20 MHz cpu bandwidth for realtime decode on a StrongARM using 27k of code) it looks like being quite a good benchmark to compare MAD against... Is it anywhere near yet ?? If not (to answer lwong's questions...) its probably due to: 1) ARM's library being written with all critical sections in assembler by ARM engineers who know the architecture inside out. 2) ARM's library may use more approximate calculations in some places. 3) Any code compiled from C will have used ARM's own c compiler which from what I've heard seems to be at least 20 percent better than gcc. ____________________________________________________________ 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

Optimisations in layer3.c
by Andre McCurdy 28 Jun '00

28 Jun '00

This list seems a little quiet, but maybe this will be of interest to someone. I've cleaning up and optimising the imdct36() function in layer3.c (where most of the execution time was being spent), with the result that its now over 30 percent faster when compiled for x86. The attached .tgz file includes the changed layer3.c, plus hacked madplay.c and Makefile which profile the imdct36() function using the pentium timestamp counter. On a different subject, does anyone have access to an ARM platform for testing ?? I would be interested to know how the MAD code (with and without my changes) compares to ARM's own mp3 decode library (which claims to use only 29 MHz of cpu bandwidth for real time decode on an ARM7 core). 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

2 1

Re: Running on Arm7
by lwong＠cheerful.com 28 Jun '00

28 Jun '00

Hello, I have try to compile the last version of this program and run on the arm7 with cpu speed is 74MHz, os is ArmLinux. With arm-asm code used, the program is using 25secs to decode a 10secs mp3 bitstream where 192kbps, 44.1kHz. Using approx 32bits code, the program is using 18secs to decode that 10secs mp3 bitstream. The mad cannot reach to realtime decoding at this cpu. I have already turn on all optimize choices. I have used same arm7 cpu and ran circuit logic mp3 decoder demo to decode some mp3 bitstreams in 128kbps, 44.1kHz. This mp3 program does not need ArmLinux, it run as standalone. The audio playback work very well. I do not know that mp3 program whether possible decoding realtime at 29MHz. Do anyone know why ? ArmLinux eat some resources ? Or some compiler tricks I need to add to speed up the program. As I know, Arm7 has 3 pipeline for processing instruction. Does normal compile not take all advantange of this CPU's structure. Regards, lwong. --------------------------------------------------- Get free personalized email at http://www.iname.com

1 0

Testing conformance of decoders
by Gabriel Bouvigne 16 Jun '00

16 Jun '00

Hello I'd like to know how conformance of decoders has to be tested. I think that there are some reference tracks, but where to got them? Regards, -- Gabriel Bouvigne - France bouvigne(a)mp3-tech.org icq: 12138873 MP3' Tech: www.mp3-tech.org

2 1

MAD 0.11.0b available
by Rob Leslie 08 Jun '00

08 Jun '00

Good news! MAD now supports the MPEG 2 extension to Lower Sampling Frequencies (24, 22.05, and 16 kHz.) In addition, the Layer III performance has improved yet again due to a new optimization that avoids the IMDCT calculation when all the inputs would be zero. I'd appreciate any testing anyone is able to do with respect to MPEG 2 LSF; I have several Layer III streams I could verify but I don't have any Layer I or II streams handy. The release: ftp://ftp.mars.org/pub/mpeg/ Cheers, -rob

2 6

re: TODO: let OSS module use native endianess
by Sean 'Shaleh' Perry 04 Jun '00

04 Jun '00

After talking to a few debian developers (all ppc and sparc), they seem to believe that letting the OSS lib handle the LE -> BE conversion is fine. Seems there are special commands for that and everything that the architecture code knows about.

1 0

Re: [mad-dev] madplay vs splay (MP3 performances)
by Nicolas Pitre 16 May '00

16 May '00

On Tue, 16 May -1, Erik Mouw wrote: > On Tue, 16 May 2000 09:47:05 -0400 (EDT), Nicolas Pitre wrote: > > On Tue, 16 May 2000, J.D. Bakker wrote: > >> At 05:30 +0200 16-05-2000, Nicolas Pitre wrote: > >> >[root@thinclient /]# date; splay -d - test.mp3 | cat > /dev/null; date > >> > >> <snip> > >> > >> Aren't you really measuring pipe/context switch latency here ? Both of > >> these suck on ARMLinux (because of the required cache flushes). This > >> benchmark may not say too much about splay performance. > > > > Task switches between threads don't require a cache flush... but the 'cat' > > process might be a problem indeed. > > > > But for the interesting case i.e. when the player is actually playing, > > it's still strange that I get opposite results than Rob's. > > > > Anyone else can compare splay vs madplay on a SA1100? > > Erm, what's wrong with "splay -d - test.mp3 > /dev/null" ? Well... Euh... I'm simply too stupid some times... Nicolas

1 0

Re: [mad-dev] madplay vs splay (MP3 performances)
by Nicolas Pitre 16 May '00

16 May '00

On Tue, 16 May 2000, J.D. Bakker wrote: > At 05:30 +0200 16-05-2000, Nicolas Pitre wrote: > >On Sun, 14 May 2000, Rob Leslie wrote: > > > >> Your binaries are probably fine, but do you want me to send you a `time' > >> program? (If so, please follow up privately.) You could try timing the pure > >> decoding time like I did by dumping the PCM output to /dev/null. > > > >OK, so I just did on SA1100 hardware for which I don't currently have > >audio output support: > > > > > >[root@thinclient /]# date; splay -d - test.mp3 | cat > /dev/null; date > > <snip> > > Aren't you really measuring pipe/context switch latency here ? Both of > these suck on ARMLinux (because of the required cache flushes). This > benchmark may not say too much about splay performance. Task switches between threads don't require a cache flush... but the 'cat' process might be a problem indeed. But for the interesting case i.e. when the player is actually playing, it's still strange that I get opposite results than Rob's. Anyone else can compare splay vs madplay on a SA1100? Nicolas

1 0

madplay vs splay (MP3 performances)
by Nicolas Pitre 16 May '00

16 May '00

In the process of searching for a good way to test my UDA1341 audio driver, I just cleaned up splay's fixpoint support a bit and created a ramdisk image with splay on it. Sorry Rob, but I couldn't resist comparing splay against madplay on a SA1100 CPU because of recent concerns about splay benchmarks, threads, etc. So here are the results. Since my ramdisk doesn't have the 'time' command, I grabbed a 'top' screen while each players were running in the background. madplay: 12:27am up 27 min, 1 user, load average: 0.17, 0.04, 0.01 11 processes: 10 sleeping, 1 running, 0 zombie, 0 stopped CPU states: 23.8% user, 0.5% system, 0.0% nice, 75.5% idle Mem: 28140K av, 13328K used, 14812K free, 0K shrd, 6144K buff Swap: 0K av, 0K used, 0K free 3752K cached PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 84 root 16 0 1272 1272 1176 S 0 23.8 4.5 0:11 madplay 85 root 1 0 872 872 704 R 0 0.5 3.0 0:00 top 1 root 0 0 512 512 440 S 0 0.0 1.8 0:02 init 2 root 0 0 0 0 0 SW 0 0.0 0.0 0:00 kswapd 3 root 0 0 0 0 0 SW 0 0.0 0.0 0:00 kflushd 4 root 0 0 0 0 0 SW 0 0.0 0.0 0:00 kupdate 34 root 0 0 500 500 436 S 0 0.0 1.7 0:00 syslogd 50 root 0 0 568 568 492 S 0 0.0 2.0 0:00 inetd 54 root 0 0 472 472 400 S 0 0.0 1.6 0:00 getty 55 root 0 0 472 472 400 S 0 0.0 1.6 0:00 getty 56 root 0 0 904 904 748 S 0 0.0 3.2 0:00 bash splay: 12:29am up 29 min, 1 user, load average: 0.12, 0.05, 0.01 13 processes: 11 sleeping, 2 running, 0 zombie, 0 stopped CPU states: 17.6% user, 0.5% system, 0.0% nice, 81.7% idle Mem: 28140K av, 13672K used, 14468K free, 0K shrd, 6144K buff Swap: 0K av, 0K used, 0K free 3752K cached PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 86 root 14 0 904 904 536 R 0 17.0 3.2 0:08 splay 88 root 0 0 904 904 536 S 0 0.5 3.2 0:00 splay 89 root 1 0 872 872 704 R 0 0.5 3.0 0:00 top 1 root 0 0 512 512 440 S 0 0.0 1.8 0:02 init 2 root 0 0 0 0 0 SW 0 0.0 0.0 0:00 kswapd 3 root 0 0 0 0 0 SW 0 0.0 0.0 0:00 kflushd 4 root 0 0 0 0 0 SW 0 0.0 0.0 0:00 kupdate 34 root 0 0 500 500 436 S 0 0.0 1.7 0:00 syslogd 50 root 0 0 568 568 492 S 0 0.0 2.0 0:00 inetd 54 root 0 0 472 472 400 S 0 0.0 1.6 0:00 getty 55 root 0 0 472 472 400 S 0 0.0 1.6 0:00 getty 56 root 0 0 904 904 748 S 0 0.0 3.2 0:00 bash 87 root 0 0 904 904 536 S 0 0.0 3.2 0:00 splay Even if splay has 3 threads running, they account for 17.5% CPU vs 23.8% CPU for madplay. Both screen snapshots were taken at the same playback time so the "TIME" comparison should be accurate too. The test file used is MPEG-1 Layer 3, joint stereo, 44100Hz, 128kbit/s. This was tested on Linux 2.3.99-pre6-rmk1-np4. /proc/cpuinfo shows: Processor : Intel StrongARM-1110 rev 5 (v4l) BogoMIPS : 194.15 Hardware : Intel-Assabet The splay version I used is the cleaned one. Its playback performances is the same as the old one, however is starts right away instead of crunching 100% CPU for few seconds. This will produce proper results if mesured with the 'time' comands. If you are interested, here are where you can find all relevant files: splay-0.8.2-fp1.tgz ftp://ftp.netwinder.org/users/n/nico/ ramdisk_img_splay.gz ftp://ftp.netwinder.org/users/n/nico/ mad-0.10.3b.tar.gz ftp://ftp.mars.org/pub/mpeg/ Nicolas

2 4

MAD 0.10.3b available
by Rob Leslie 13 May '00

13 May '00

I put up MAD 0.10.3b, which includes the patch I posted earlier, and as an added bonus also includes an experimental Win32 audio output module. MAD compiles and runs cleanly under Win32 using the latest cygwin. The Win32 audio interface I wrote has some problems, however. Layer II and Layer III work fine on a fast machine with low load, but Layer I or a machine with high load causes the output to be choppy. I think the problem has to do with the relatively small PCM buffer size (currently the output size of a single MPEG audio frame, where Layer I is 1/3 the size of Layer II or III) and the uncertainty of process scheduling... but another part of me really wants to blame Microsoft for their retarded audio API. At some point I'll improve this to do my own buffer coalescing which should help. If anyone has experience or advice with respect to Win32 audio I'd be grateful to hear it. The release: ftp://ftp.mars.org/pub/mpeg/ Cheers, -rob

1 0

skipping around
by Sean 'Shaleh' Perry 09 May '00

09 May '00

Is skipping around not possible with the synchronous high level API? The mad_decoder_command() seems to simply kill the playback.

2 2

MAD 0.10.2b available
by Rob Leslie 07 May '00

07 May '00

At long last, I have rewritten the Layer III long block 36-point IMDCT routine to make better use of symmetry and to reuse common subexpressions. I'm not convinced this is the best possible rewrite, but it is better for performance than what was before. The change involves a slight time/space trade-off, but since MAD is already pretty good with memory I think the change is worth it. Together with the changes from 0.10.1b, the CPU performance improvements are building up: (StrongARM 1100 220MHz) decoder version Layer I Layer II Layer III ------------------------------------------------------------------------------- MAD 0.10.2b (SSO) 18% 17% 28% MAD 0.10.1b (SSO) 18% 17% 31% MAD 0.10.0b 23% 22% 37% (Celeron 500A) decoder version Layer I Layer II Layer III ------------------------------------------------------------------------------- MAD 0.10.2b (SSO) 3% 3% 6% MAD 0.10.0b 4% 4% 7% I suspect the next thing to be done is to modify the way Layer III decoding is performed such that requantization happens at the same time as Huffman decoding, instead of in a separate pass. This should reduce memory usage again as well as help performance. The latest release can be found here: ftp://ftp.mars.org/pub/mpeg/ Cheers, -rob

2 3

anyone looked into Ogg vorbis yet?
by Sean 'Shaleh' Perry 27 Apr '00

27 Apr '00

http://www.xiph.org/ogg/vorbis/ It is a mp3 like encoding / decoding CODEC. Still real early, but seemingly with promise and a dedication to release. It claims to be patent free and open, although the company (xiph) is keeping the codec itself under their control.

2 2

can you explain dct32()?
by Sean 'Shaleh' Perry 25 Apr '00

25 Apr '00

Hi, I am trying to ponder out what dct32 is actually doing. The comment in matrixing() reads: 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 the hi and lo are only 16 entries, filter is 32. 'i + 32' and definately 'i + 48' go beyond these bounds. Now, I understand matrix math, but the numbers just don't seem right here.

2 4

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

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