The current file playback ends <Buffer size option value> ms earlier
Steps to reproduce¶
1. Set Audio=>Buffer size option value to 10'000 ms in Audacious Settings.
2. Restart Audacious to make sure that the configuration takes effect.
3. Play a short file (longer than 10 seconds). Alternatively seek close to the end of a longer file (but not as close as 10 seconds).
4. Look at the audio progress bar until the playback ends.
The UI reports that the current track playback ends 10 seconds before the progress bar reaches the end. The next track appears to start 10 seconds earlier. The next-track desktop notification appears 10 seconds earlier. A configured Song Change command runs 10 seconds earlier. And so on. The exception is the actual audio playback itself: it ends in time - 10 seconds later than the UI indicates.
The Buffer size option value does not affect the UI and General plugins.
I have recently increased my Buffer size to 2500 ms because of playback stuttering during heavy filesystem use by other programs. I have noticed this issue because I had configured starting playback of a next file as a custom Command to run at the end of the playlist in Song Change plugin. Therefore the last two seconds of audio of the last playlist item are cancelled by the next scheduled file playback. A workaround is to delay running the custom command by Buffer size ms:
But the next-track desktop notification still appears too early.
bash -c "sleep 2.5 && <custom command>"
#2 Updated by Igor Kushnir about 2 months ago
John Lindgren wrote:
This is the way it's designed to work. The playlist (and therefore most of the UI) follows the track currently being decoded. The audio stream will lag behind more or less depending on buffering.
This looks like a design mistake then, because users usually care which track is currently playing, not which one is being decoded. I think the bug should remain open - perhaps it will be addressed during a future major overhaul of the relevant code.