Audacious can stutter badly on some live HTTP radio streams even when the network buffer is set to a very large value, for example 1 MB.
This appears to be because the network buffer setting controls only the maximum buffer capacity, but Audacious starts playback after only a tiny amount of data has been read. In other words, increasing the network buffer size does not necessarily mean Audacious will wait until a useful amount of data has actually been buffered before starting playback.
This makes the setting much less useful for live radio streams with bursty or jittery delivery.
Observed behavior:
- Some Icecast/Shoutcast-style HTTP streams stutter repeatedly in Audacious.
- Increasing the network buffer size, even to 1 MB, does not reliably fix the issue.
- Other players, including Winamp and MPV, can handle the same problematic streams without stuttering, presumably because they prebuffer a useful amount of stream data before playback starts or resumes.
Expected behavior:
For live HTTP streams with unknown length, Audacious should prebuffer a reasonable amount of data before starting playback.
Similarly, after a full network-buffer underrun, Audacious should not resume playback immediately after receiving only a tiny amount of data. It should re-enter a short prebuffering phase first.
Actual behavior:
Audacious appears to start or resume playback after very little data is available. As a result, the playback buffer can underrun repeatedly on streams whose delivery is bursty, even when the configured network buffer size is large.
Why this matters:
A large network buffer is expected to help with network jitter. Currently, it mostly acts as a maximum capacity limit, not as a useful startup/resume prebuffer. This makes Audacious more fragile than older players such as Winamp on broken or poorly configured Icecast/Shoutcast servers.
This is especially frustrating because users cannot make third-party radio stations fix their servers. A media player should be reasonably tolerant of real-world stream behavior.
Likely area:
The issue appears to be in the Neon HTTP transport plugin.
The current behavior seems to be approximately:
network buffer size = maximum capacity
startup threshold = very small / first successful read
A more useful behavior would be:
for live / unknown-length HTTP streams:
wait until a modest amount of data is buffered before starting playback
after complete underrun:
prebuffer again before resuming playback
I have tested a small proof-of-concept patch against src/neon/neon.cc which adds conservative prebuffering for unknown-length live streams. It does not affect normal known-length HTTP files.
The patch uses a threshold based on the configured network buffer size, but caps it to avoid excessive startup delay:
prebuffer = clamp(network_buffer_size / 4, 4096 bytes, 128 KiB)
Examples:
Network buffer 128 KiB -> prebuffer about 32 KiB
Network buffer 512 KiB -> prebuffer about 128 KiB
Network buffer 1 MiB -> prebuffer capped at 128 KiB
This should make the network buffer setting behave more like users expect for live streams: not just “how much may be buffered,” but also “have enough data before starting/resuming playback to ride out short delivery stalls.”
This is not intended to fix servers that stop sending data for longer than the available buffer can cover. It is intended to fix the avoidable case where Audacious starts/resumes playback with almost no useful buffered data despite the user having configured a large network buffer.
audacious-plugins-neon-stream-prebuffer.patch
Audacious can stutter badly on some live HTTP radio streams even when the network buffer is set to a very large value, for example 1 MB.
This appears to be because the network buffer setting controls only the maximum buffer capacity, but Audacious starts playback after only a tiny amount of data has been read. In other words, increasing the network buffer size does not necessarily mean Audacious will wait until a useful amount of data has actually been buffered before starting playback.
This makes the setting much less useful for live radio streams with bursty or jittery delivery.
Observed behavior:
Expected behavior:
For live HTTP streams with unknown length, Audacious should prebuffer a reasonable amount of data before starting playback.
Similarly, after a full network-buffer underrun, Audacious should not resume playback immediately after receiving only a tiny amount of data. It should re-enter a short prebuffering phase first.
Actual behavior:
Audacious appears to start or resume playback after very little data is available. As a result, the playback buffer can underrun repeatedly on streams whose delivery is bursty, even when the configured network buffer size is large.
Why this matters:
A large network buffer is expected to help with network jitter. Currently, it mostly acts as a maximum capacity limit, not as a useful startup/resume prebuffer. This makes Audacious more fragile than older players such as Winamp on broken or poorly configured Icecast/Shoutcast servers.
This is especially frustrating because users cannot make third-party radio stations fix their servers. A media player should be reasonably tolerant of real-world stream behavior.
Likely area:
The issue appears to be in the Neon HTTP transport plugin.
The current behavior seems to be approximately:
A more useful behavior would be:
I have tested a small proof-of-concept patch against
src/neon/neon.ccwhich adds conservative prebuffering for unknown-length live streams. It does not affect normal known-length HTTP files.The patch uses a threshold based on the configured network buffer size, but caps it to avoid excessive startup delay:
Examples:
This should make the network buffer setting behave more like users expect for live streams: not just “how much may be buffered,” but also “have enough data before starting/resuming playback to ride out short delivery stalls.”
This is not intended to fix servers that stop sending data for longer than the available buffer can cover. It is intended to fix the avoidable case where Audacious starts/resumes playback with almost no useful buffered data despite the user having configured a large network buffer.
audacious-plugins-neon-stream-prebuffer.patch