Michael Truog

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.

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 .

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.,

Thank you for the suggestion. I will try using -i / --index instead of -b for NFS delays.

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...

On 11/4/23 00:50, Thomas Orgis wrote: 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...

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...