Bugzilla – Bug 14117
Sync streaming can consume lots of memory when one player connection slow
Last modified: 2012-01-31 23:31:21 UTC
The logic in Slim::Player::Source::nextChunk() can cause many chunks of data to be queued up in memory for one player if it is slow, or the network connection to it is slow, and a different synced player is achieveing fast throughput. The maximum is given by the sum of the (fast) player's decode buffer and the network pipeline which is bounded by the TCP window and the kernel TCP stacks on either end. In the case of a SliMP3 in the mix, its small buffer and the user-space UDP protocol pretty-much guarantee that this situation will arise.
== Auto-comment from SVN commit #31739 to the slim repo by ayoung == == http://svn.slimdevices.com/slim?view=revision&revision=31739 == Fixed bug 14117: Sync streaming can consume lots of memory when one player connection slow Use a high-water-mark (10) and low-water-mark (3) to ensure that the number of outstanding chunks of audio data to different synced players cannot get too out of step. This avoids the problem of lots of audio data buffered in SbS memory. It has the secondary advantage that bandwidth to all the clients in a sync-group will be shared more fairly, especially at track startup, which should lead to less chance of one client causing stuttering.
Whilst this particular problem may have been fixed it has introduced a problem with sync'd players trying to listen to the BBC iPlayer stream. Should a new bug be opened or is someone going to go back and fix it? I'm just a user who has found that what worked fine previously doesn't now. So I'd be happy with a workround that let me use the service as I did before.
Please open a new bug and reference this one.