Frequently Asked Questions
Since several nice people are offering translations of this page into belarusian, in exchange for an innocent link, I thought it might be helpful if I point out that you can get very similar translations from your friendly all-knowing internet overlord: Google translate. In fact, you even have a choice of more than one eastern european language...
mpg123 does only play the intro jingle of my web radio!
This should be fixed in upcoming 1.14 release, please test the beta version!
This might be collateral damage from a feature of mpg123 -- the gapless playback using sample-exact length and padding information provided at the beginning of an MP3 stream. It makes perfect sense for files, and actually should only be present there. Now, some web radios just insert such a single file with that special gapless header into the radio stream and make mpg123 believe it is just playing a single small file where it should cut off some trailing silence -- that trailing silence effectively including the actual radio stream!
Use of the --no-gapless command line switch might help, or the unsetting of the MPG123_GAPLESS flag when using libmpg123. Further information and discussion about possible changes of mpg123's smarts about this are to be found in mailing list archives, one thread on the devel list, one thread on the users list.
If you are terminally offended by those, disable the assembly optimizations.
I am trying to use libmpg123 and I am confused by the output format stuff.
Read the updated overall description of the format API. If that does not help, please ask for clarification.
I want to port some old code using mpglib to libmpg123.
For that case, the feeder API has been introduced in addition to the file-based API. Have a look at the examples, specifically the mpglib-like example. Make also sure to read the API documentation about the feeder API ... and the stuff about output formats.
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:
- Make sure you use off_t properly for all file offsets (mpg123 API, but also other file I/O).
- Add -D_FILE_OFFSET_BITS=64 to your compiler flags -- for the whole build.
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.
I want to compile with Alsa but configure fails - what do I need?
Most likely, you are missing the header files for the alsa library (libasound) or even the library itself.
|Debian / Ubuntu||libasound2, libasound2-dev|
I want a fresh RPM of mpg123!
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
No sound on my AMD64 / x86_64 machine!
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.