[PR #402] [MERGED] Limit number of requests for pre-fetching #912

New issue

Closed

opened 2026-02-27 20:00:25 +03:00 by kerem · 0 comments

kerem commented

2026-02-27 20:00:25 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/librespot-org/librespot/pull/402
Author: @kaymes
Created: 11/19/2019
Status: ✅ Merged
Merged: 12/2/2019
Merged by: @sashahilton00

Base: dev ← Head: limit-request-number

📝 Commits (2)

db0e4a0 Limit number of prefetch requests.
e550b7f rustfmt

📊 Changes

1 file changed (+45 additions, -21 deletions)

View changed files

📝 audio/src/fetch.rs (+45 -21)

📄 Description

I noticed some ocational buffer under-runs as a consequence of PR #393 for which I made a fix here.

The issue is, that the pre-fetch algorithm can potentially fire of lots of small requests to keep the amount of pending bytes at the desired level. If bandwidth limits are hit, this leads to responses being interleaved - all requests are served simultaneously, which means the total data rate is great but each single request experiences a low data rate. A consequence can be, that the first request isn't responded to in time and we get a buffer under-run.

I solved this by limiting the amount of open requests when pre-fetching: a pre-fetch request is only sent when less than 4 requests are open. This leads to less requests which are larger. Thus, individual requests should still get decent download rates.

I experimented with different values. Using a limit of 3 leads to significantly lower overall download rates. Thus, I chose 4.

I also increased the amount of data that is requested ahead of the current read positions.

So far I haven't had any more buffer under-runs with these changes. Fingers crossed.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/librespot-org/librespot/pull/402 **Author:** [@kaymes](https://github.com/kaymes) **Created:** 11/19/2019 **Status:** ✅ Merged **Merged:** 12/2/2019 **Merged by:** [@sashahilton00](https://github.com/sashahilton00) **Base:** `dev` ← **Head:** `limit-request-number` --- ### 📝 Commits (2) - [`db0e4a0`](https://github.com/librespot-org/librespot/commit/db0e4a04227e72abd8ad25322955ff817cd813d0) Limit number of prefetch requests. - [`e550b7f`](https://github.com/librespot-org/librespot/commit/e550b7f7299a7e505d6b19559ecf1fc079a8df20) rustfmt ### 📊 Changes **1 file changed** (+45 additions, -21 deletions) <details> <summary>View changed files</summary> 📝 `audio/src/fetch.rs` (+45 -21) </details> ### 📄 Description I noticed some ocational buffer under-runs as a consequence of PR #393 for which I made a fix here. The issue is, that the pre-fetch algorithm can potentially fire of lots of small requests to keep the amount of pending bytes at the desired level. If bandwidth limits are hit, this leads to responses being interleaved - all requests are served simultaneously, which means the total data rate is great but each single request experiences a low data rate. A consequence can be, that the first request isn't responded to in time and we get a buffer under-run. I solved this by limiting the amount of open requests when pre-fetching: a pre-fetch request is only sent when less than 4 requests are open. This leads to less requests which are larger. Thus, individual requests should still get decent download rates. I experimented with different values. Using a limit of 3 leads to significantly lower overall download rates. Thus, I chose 4. I also increased the amount of data that is requested ahead of the current read positions. So far I haven't had any more buffer under-runs with these changes. Fingers crossed. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

kerem

2026-02-27 20:00:25 +03:00

closed this issue
added the
pull-request
label

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/librespot#912

No description provided.

Rows
Columns