mad-dev

mad-dev@lists.mars.org

682 discussions

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

Jump to page:

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