madplay on MIPS

madplay on MIPS

[Hartvig Ekner]

I seem to recall somebody asking about madplay mp3 player about a week
ago. For what it's worth, we just ran mad-0.14.2b on our Malta board
with the 2.4.3 kernel, and it works without a hitch (so far only LE
tested). CPU utilization is around 25% of a 200 MHz CPU.

The soundcard was a Creative SB card, based on the Ensoniq chip and
using the es1371.c driver.

/Hartvig

-- 
 _    _   _____  ____     Hartvig Ekner        Mailto:hartvige@mips.com
 |\  /| | |____)(____                          Direct: +45 4486 5503
 | \/ | | |     _____)    MIPS Denmark         Switch: +45 4486 5555
T E C H N O L O G I E S   http://www.mips.com  Fax...: +45 4486 5556

Re: madplay on MIPS

[Pete Popov]

On Thu, 2002-02-07 at 10:46, Hartvig Ekner wrote:
> I seem to recall somebody asking about madplay mp3 player about a week
> ago. For what it's worth, we just ran mad-0.14.2b on our Malta board
> with the 2.4.3 kernel, and it works without a hitch (so far only LE
> tested). CPU utilization is around 25% of a 200 MHz CPU.
> 
> The soundcard was a Creative SB card, based on the Ensoniq chip and
> using the es1371.c driver.

OK, thanks. I'll take a look at the es1371 driver.

Pete

madplay on mips

[Pete Popov]

Has anyone used madplay on mips to play mp3 files successfully? I've
tried it on two mips boards with different sound drivers, and in both
cases it plays the song slower and a bit muffled.  It works on x86 and
supposedly ppc.

Pete

Re: madplay on mips

[Jun Sun]

Pete Popov wrote:
> 
> Has anyone used madplay on mips to play mp3 files successfully? I've
> tried it on two mips boards with different sound drivers, and in both
> cases it plays the song slower and a bit muffled.  It works on x86 and
> supposedly ppc.
> 

I tried it before, and had the same results.

I looked over the system calls, and was pretty much sure that the problem was
on madplay side, and not on the driver side.  One problem suspected was the
floating point issue, but did get into it.

Jun

Re: madplay on mips

[Pete Popov]

On Mon, 2002-02-04 at 10:42, Jun Sun wrote:
> Pete Popov wrote:
> > 
> > Has anyone used madplay on mips to play mp3 files successfully? I've
> > tried it on two mips boards with different sound drivers, and in both
> > cases it plays the song slower and a bit muffled.  It works on x86 and
> > supposedly ppc.
> > 
> 
> I tried it before, and had the same results.
> 
> I looked over the system calls, and was pretty much sure that the problem was
> on madplay side, and not on the driver side.  One problem suspected was the
> floating point issue, but did get into it.

Even though madplay claims that no floating point is used, the
disassembly of the latest version shows otherwise. But I tried it on a
board with a cpu that does have a hardware floating point unit with the
same result.

Pete

Re: madplay on mips

[Rob Leslie]

Pete Popov wrote:
> Has anyone used madplay on mips to play mp3 files successfully? I've
> tried it on two mips boards with different sound drivers, and in both
> cases it plays the song slower and a bit muffled.  It works on x86 and
> supposedly ppc.

Muffled sound could be the result of a poor FPM choice, or a buggy compiler.

For best performance, MAD needs a multiply/accumulate instruction, which is
not available on all MIPS platforms. Check the MIPS section of libmad/fixed.h
and see whether you can use either of the MADD_ASM alternatives, then change
your libmad/config.h to suit (or consider updating libmad/configure.in). In
the worst case you might need to write a new asm alternative, or try something
more generic like FPM_64BIT or FPM_DEFAULT -- though the latter could also be
the cause of poor sound.

I've encountered problems with certain gcc optimization options on some
platforms, notably ARM and MIPS, the symptom being a sort of muffled sound
result rather than the clear sound MAD ought to produce. I never traced these
bugs in the compiler, so my only advice is to try different combinations of
-fstrength-reduce and -finline-functions if you suspect this to be a problem.

> Even though madplay claims that no floating point is used, the
> disassembly of the latest version shows otherwise. But I tried it on a
> board with a cpu that does have a hardware floating point unit with the
> same result.

The _only_ floating point used by madplay is in option parsing and calculation
of peak amplitude in decibels upon completion of decoding. There is no
floating point used in the decoder proper (libmad).

I'm not sure what you mean by songs "playing slower" but it could be either
libmad is not reaching real-time performance, or there could be issues with
channel/sampling frequency selection in your sound driver. You could try -m
and/or --downsample, or modify the audio output module to use a fixed known
good sampling frequency. Also try sending output to a file (-o out.wav) and
see if you can play that successfully with another program.

If the problem is real-time performance, you can try the --enable-speed option
to `configure' at the expense of some accuracy.

-- 
Rob Leslie
rob@mars.org