command-line argument -b causes current track output to be invalid
Brought to you by:
sobukus
When using the mpg123 command-line argument "-b 65536" with multiple songs from an album, the current track is displayed as a future track due to the buffering and due to that the output becomes confusing. This can be easier to see when using the "-C" command-line argument with the terminal interface. The current track output becomes wrong in any way it is printed with the terminal interface.
True. The positiion info takes that somewhat into account, but mpg123
prints new track info as it appears from the decoder. It's not cached in
the player. The decoder library moved on to the next track while the
buffer still plays the old one.
Considering that this has been that way for rather many years, since the
buffer first entered, we might call it a feature request to do otherwise.
It can be done, but people weren't bothered enough by the current state
yet.
What is your use case for the buffer, actually? Is it on a system that
would otherwise not manage smooth audio? Is it about network trouble?
In the later case, an input buffer would be more sensible, actually.
It seems like you would prefer using "--preload 1" which must be maximizing the input buffer. The reason I was using "-b 65536" was to avoid any potential NFS delays that would impact playback. The man page for version 1.25.13 (dated 29 Feb 2016) says "If you suffer from short network outages, you should try the -b option (buffer) to bypass such outages.". So, based on the man page "-b" should be more appropriate for network trouble. I understand this current track output problem has existed for a long time and people don't appear to have noticed it, but I have trouble considering erroneous output a feature, even if the erroneous output has occurred for a long period of time. I was hoping I could both use "-b" and avoid being constantly lost in music, at the same time. If the current track was always correct, it would help for referencing track info for lyrics or background information (i.e., just based on reading the text output).
Last edit: Michael Truog 2023-11-04
Last edit: Michael Truog 2023-11-04
Regardless of fixing the display issue or not ... for your case --index
might do the trick. It should fill the filesystem cache with the track,
in exchange for a small pause beween tracks. But for typical file sizes,
this should be really small.
Thank you for the suggestion. I will try using -i / --index instead of -b for NFS delays.
When I tried -i / --index with 1.25.13, when using the command-line:
mpg123 --index --smooth -C FILE.mp3
I experienced audio distortion at the beginning before it jumps into the single file, later in its contents. The version might be too old, so I might try --index in a future version after I update the Linux install in the future. The file I was experimenting with is larger, (41863756 bytes, i.e., Jethro Tull - Thick As a Brick) if that is relevant.,
Pulseaudio? There's (or was) a bug in the ALSA wrapper that results in static noise at stream beginning (or interruption).
Maybe -o pulse to use pulse directly fixes it in this case.
Using the default -o alsa was the cause of audio distortion and using -o pulse instead avoids that. Thanks! Will try using --index more instead of --buffer .
It looks like --index is a good way of avoiding the problem. I really like the --buffer option though and will continue to use that with an older mpg123 release (due to an unrelated NFS client incompatibility I ran into that leads to update problems). Thanks! Feel free to close this.
Oh, I just realized that I did 'fix' that behaviour in the meantime. With 1.29.3 (Ubuntu 22.04) you already have buffer draining after each song. This has the effect of the new track info only appearing once the new track starts. If you want absolutely no pause between tracks, you can give
--smoothto avoid the draining. This has the downside of restoring the early printout of track info.But you can choose: Properly timed information or absolutely smooth playback. The use of
--indexis probably overkill. Or maybe not. Well, you have options, some of which will make you happy, I hope.But you should really try to advance from 1.25.x for this.
It should be not that hard to build current mpg123 for your system. You just need libpulse0-dev (or how it's called) for the audio output and basic build stuff (gcc, libc headers, aka
build-essentials).