[SlimDevices: Audiophiles] Re: Buffering on the SB3
It's got 64Mb of RAM. If you switch off the network or the server it will continue to play for maybe 30 seconds, depending on how full the buffer was (the time might also depend on what file format you're streaming - possibly streaming mp3 it would last longer - but I haven't experimented). I don't think there's any way to turn off the buffer - the SB wouldn't function with the buffer off. -- opaqueice opaqueice's Profile: http://forums.slimdevices.com/member.php?userid=4234 View this thread: http://forums.slimdevices.com/showthread.php?t=32248 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: Buffering on the SB3
You could try the Network test plugin from the Sb which is used to measure sustained throughput from a source - AFAIK buffering is not an issue in this test. Some measure of SB buffering can be adjusted from 3 secs to 30 secs from the Slimserver menu. I think a significant issue for streaming radio would be latency - with live streams buffering helps but if packets are too late the buffer gets depleted and eventually link stutters and breaks down. Large buffers help delay this effect, but if the buffer is too large then it is possible for packets to be held for too long before they are read, acked and played and so you can get TCP/IP reset. -- bpa bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=32248 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: Buffering on the SB3
Triode;175847 Wrote: SB3 will be a good demo, but only because it has a reasonable amount of buffering and hence you will get good performance.. Its designed to cater for Wifi dropouts so a 50ms protection switch is nothing for it. Data is transfered from the server to player using a tcp connection and then dumped into the internal buffer. Better demo would be the old SB1 streaming WAV as that only had 0.5 sec of buffer. I agree except I am trying to demo the Fast Reroute Capabilities of our network equipment, not the buffering capability of the SB. Our equipment can protect and reroute around failures in about 50 m/s. If the end device (i.e SB) is buffering 500 m/s of content, I am not proving much. Anyone have any idea on the buffering capabilities of softsqueeze? -- sfraser sfraser's Profile: http://forums.slimdevices.com/member.php?userid=2026 View this thread: http://forums.slimdevices.com/showthread.php?t=32248 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: Buffering on the SB3
I was trying to say its much more than 50ms - its of the order of 10secs or more depending on the data rate you are streaming at. [put I liked to do demos which always worked] -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=32248 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: Buffering on the SB3
I think a 50msec changeover is a bit irrelevant to a TCP connections as long as the basic comms link stays up. If there is a glitch which results in packet corruption/loss, TCP will arrange retransmissions as long as the TCP connections is maintained. If the retransmission can occur such that the missing packet arrive in time, then there will be no gaps in the audio. If the changeover resulted in some loss of sync or similar which resets the TCP connection then there would be a problem regardless of the amount of buffering. So if you are demoing that physical comms path can be changed (e.g. onto a different fibre in a SDH ring) without interrupting/breaking/resetting the TCP connections, the SB will be ideal and the amount of buffering won't really matter. -- bpa bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=32248 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: Buffering on the SB3
bpa;175886 Wrote: I think a 50msec changeover is a bit irrelevant to a TCP connections as long as the basic comms link stays up. If there is a glitch which results in packet corruption/loss, TCP will arrange retransmissions as long as the TCP connections is maintained. If the retransmission can occur such that the missing packet arrive in time, then there will be no gaps in the audio. If the changeover resulted in some loss of sync or similar which resets the TCP connection then there would be a problem regardless of the amount of buffering. So if you are demoing that physical comms path can be changed (e.g. onto a different fibre in a SDH ring) without interrupting/breaking/resetting the TCP connections, the SB will be ideal and the amount of buffering won't really matter. Your right, I obviously did not read the other post close enough, I thought the SS streamed via UDP not TCP. As long as the SB can buffer long enough to send/receive the retransmit request/reply for a lost packet or two, all is good. We are using RSVP-TE FRR on MPLS service router platforms. Most failovers actually occur in and around 20-30 m/s. The impact to Ethernet services, and customer applications running on this infrastructure is rather negligable. TCP session dropping, will not be an issue. If i can crank down the buffer size so the SB cannot tolerate a large amount of packet drops i may have a interesting demo on my hands. (and a good excuse to pick ip a old SB1 ) -- sfraser sfraser's Profile: http://forums.slimdevices.com/member.php?userid=2026 View this thread: http://forums.slimdevices.com/showthread.php?t=32248 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: Buffering on the SB3
Buffer size is implemented in the player firmware and is not user adjustable I'm afraid. -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=32248 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: Buffering on the SB3
Does the winamp streaming method use the buffer in a different way? I thought there was a way to do real-time PC sounds through a squeezebox, but have never used it. Apologies if I'm way off base. -- Skunk Skunk's Profile: http://forums.slimdevices.com/member.php?userid=2685 View this thread: http://forums.slimdevices.com/showthread.php?t=32248 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: Buffering on the SB3
The original Slimdevices SLiMP3 device used UDP and there are some software emulators for it on Linux (e.g. slimp3slave) but I've no idea whether the emulator still works nor the buffer size. There are still slimp3 users using current version of slimserver so if you still want an UDP stream it may be worth trying. -- bpa bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=32248 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
