Project

General

Profile

Bug #1073

The current file playback ends <Buffer size option value> ms earlier

Added by Igor Kushnir about 3 years ago. Updated about 2 years ago.

Status:
Rejected
Priority:
Minor
Assignee:
-
Category:
-
Target version:
-
Start date:
February 22, 2021
Due date:
% Done:

0%

Estimated time:
Affects version:

Description

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.

Actual result

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.

Expected result

The Buffer size option value does not affect the UI and General plugins.

Additional information

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:

bash -c "sleep 2.5 && <custom command>"
But the next-track desktop notification still appears too early.

History

#1 Updated by John Lindgren about 3 years ago

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.

#2 Updated by Igor Kushnir about 3 years 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.

#3 Updated by John Lindgren about 3 years ago

I personally hope there aren't any more major overhauls of the relevant code.

#4 Updated by John Lindgren about 2 years ago

  • Status changed from New to Rejected

Closing this as "won't fix"; the effort required is too high for a small benefit.

Also available in: Atom PDF