I was waiting for someone else to verify this fixes it (also had positive report from Richard Titmuss) so am now happy this is a problem that needs fixing.
The disadvantage of simply taking the current code and making RETRY_TIME lower is higher cpu load when streaming low rate streams on a slow server. I played with this and it decided against proposing it as a default change - however with direct streaming for mp3 streams for SB2 this may now be more of an option. The problem is that linux 2.4 only buffers 4096 bytes in a pipe [linux 2.6 and windows allow buffering of larger blocks, there are probably other OSs which are limited to 4K as this is a page size]. Depending on how different tasks are scheduled you get the case where slimserver reads 4096 bytes, tries again and gets nothing and so does not try again for RETRY_TIME. In parallel, mplayer can write 4K and then blocks until the pipe is emptied. Hence 4096 / RETRY_TIME must have enough bandwidth to sustain a pcm stream [which default values don't] Let me raise a bug on this and we can discuss how it should be fixed. I believe it should impact any streaming to pcm/flac via an external app [do you get the same with ogg?] Adrian -- Triode _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/plugins
