PDA

View Full Version : Curious-- SB3 wouldn't turn OFF



dgpretzel
2006-09-22, 12:06
Last night I downloaded and installed 6.5 on a new Windows XP Pro machine. I got rid of the former SS machine several weeks ago (recently, I have been mostly using my SB3 with SN). Anyway, it installed fine.

I configured the SB3 for wireless, and it worked fine, too (firmware upgraded automatically).

I then started playing an internet radio station (WDAV in Charlotte, NC) and listened for a while.

Later, I shutdown the server and powered down the computer.

The SB continued to play. I expected the SB to stop when I powered down the server.

I fiddled around with the remote, and observed that the display was back at the initial screen. Pressing POWER OFF on the remote did nothing (I guess that would make sense since the server was off by that time). Then, I noticed that the SB screen was totally black, but the music continued playing. I let it play for a little while, then finally pulled the plug.

I wonder why it continued to play in the absence of either a local SS or remote SN connection?

Could it be that it was just playing from its local cache, even after the server disappeared?

DG

kdf
2006-09-22, 12:14
Quoting dgpretzel <dgpretzel.2ejvmn1158952201 (AT) no-mx (DOT) forums.slimdevices.com>:

> Could it be that it was just playing from its local cache, even after
> the server disappeared?
>
Depending on the format of the music being played, it could keep going
for quite a while on just what is buffered in the player itself. The
SB2/3 were given a big boost in ram to avoid any network lag causing
dropouts (as would happen in some cases with the SB1 models)

-kdf

dgpretzel
2006-09-22, 13:47
How does the buffering actually work? I mean usually it takes only a few seconds for buffering to be completed. Then the music starts. Presumably, on average, the data rate in equals the data rate out. Thus, the amount of data buffered should be whatever was accumulated during the initial buffering process, which is several seconds' worth.

How then can the buffer supply data for more than a minute after the incoming data stream terminates?

Curious,

DG

kdf
2006-09-22, 14:02
Quoting dgpretzel <dgpretzel.2ek09b1158958201 (AT) no-mx (DOT) forums.slimdevices.com>:

>
> How does the buffering actually work?

SB3 Buffer is, from the wiki,
http://wiki.slimdevices.com/index.cgi?HardwareComparison:

25Mb (approx. 200 seconds at 128Kbps) compresessed
, plus 28Mb (10 seconds at 44.1 samples/sec) uncompressed

In order to play music with a fast response, an initial threshold
triggers the start of playback. The bandwidth of a typical network is
a lot more than the playback rate, so you can continue to fill the
buffer during playback. In cases of compressed audio in formats
native to to the hardware, the data can be sent whie still compressed
and thus filling at an even greater rate than the playback.

As such, on a solid network where the buffer is not being reduced
periodically from lag, you end up with up to 200 seconds of compressed
audio stored on the hardware. Even after SN or slimserver is gone,
the hardware continues playing since that was the last instruction
given before the server went away.

-kdf

andyg
2006-09-22, 14:03
In 6.5 we use a different method for radio called direct streaming. The player actually makes the audio connection directly to the remote server (or via a proxy if you've set that option). So without an SS/SN connection it will continue to play as long as you still have a net connection. Upon reconnecting to SS the audio will stop. On SN, the audio is allowed to continue after reconnect, so that you can listen uninterrupted even if you are bounced around several SN instances.

dgpretzel
2006-09-22, 15:12
"from the wiki"

Oops. Apologize for not doing my homework.





"In 6.5 we use a different method for radio called direct streaming. The player actually makes the audio connection directly to the remote server..."

Ahah! That explains it. The SB was playing (with no connection to SS or SN) for >3 minutes. Maybe 5 minutes. So, although I didn't really know how big the buffer was, I guessed that it was not THAT big. Now I see.


DG