You just installed the fast and lean UNIX command line MPEG audio player and gaze agape at the high CPU load you see while playing a track. You even have a standard GNU/Linux setup with ALSA sound, no fancy audio daemons roaming around... is mpg123 such a CPU hog?
Check the CPU load of
mpg123 -a hw:0,0 myfile.mp3
That uses the ALSA hardware (sort of) directly without the software layer in between, that can and will do up/downmixing, format conversion and resampling. If that has lower CPU usage, then it may well be that ALSA decided to open your audio hardware at 48kHz and resamples your 44.1kHz file for playback on the fly. The default resampling seems to be of the rather expensive type, easily beating the whole MPEG decoding business. You can configure the default audio device to behave differently, choose the sample rate, lower quality resampling, etc. Please refer to ALSA documentation how to do that, or just use the hardware directly as indicated above, if that works for your setup (sharing the device with other apps, etc).
It may be an additional bug that on my (Thomas) machine, the CPU load with the ALSA default device increases after some time to a ridiculous number of around 30% (on a Core2Duo, clocked between 800 and 1200MHz).
That request is coming quite often. The issue is that current mpg123 and libmpg123 is LGPL and I as maintainer am fine with usage of code from mpg123 under these terms, while the mpglib in LAME is older and still under GPL. There may be changes to the mpglib made by people who don't want their work used under LGPL instead of GPL. I don't know how relevant this issue is, but it is a concern by the LAME developers.
Please read some mails to the lame-dev list for elaboration.
The solution to the whole mess would be to find a bit of manpower to change LAME to use libmpg123. It should be not that hard, especially since the mpg123 (svn trunk, at least) supports floating point output as runtime option. There may be more requirements by LAME that need some tweaks in libmpg123, but assessing that need is part of the manpower thing. LAME and mpg123 development teams are small and not paid for that work (AFAIK that's the case for both). Your help is appreciated.
You try to compile a program using libmpg123 on GNU/Linux or Solaris and get this:
/usr/local/include/mpg123.h:37:2: error: #error "Mismatch in large file setup!
Enable/disable large file support appropriately to use libmpg123."
This is due to libmpg123 being compiled with large file support and your app is trying to compile without... or the other way round. Usually, it is the case that you upgraded to mpg123 1.6, which enabled large file support as default and your app build fails to use the switch for enabling large support.
The usual case is resolved by this:
Note that just disabling large file support in libmpg123 may be an option, but not a smart move. Everyone should use large file support nowadays and GNU/Linux distributions use it as default.
You are living in the past. See my message to the asterisk community.
Most likely, you are missing the header files for the alsa library (libasound) or even the library itself.
| Distro | Needed packages |
|---|---|
| Debian / Ubuntu | libasound2, libasound2-dev |
Your distro does not contain a current mpg123 and but you still want to install it properly via rpm...
You can simply download the source and use rpmbuild -- see Michael's HOWTO
See bug 1547470. There is an issue with alsa < 1.0.13 that breaks mpg123 when compiled with 64bits (on this platform only?). So just upgrade alsa and it should be fine.