PDA

View Full Version : Internet streaming / Multiple Squeezebox synching - Is itpossible?



Steven L. White
2004-01-11, 11:34
For everyone having streaming problems, I'm curious to which streams
(thus their protocols) are working and which aren't (HTTP, raw UDP, RTSP
via UDP, RTSP via TCP, SIP, etc.) and how long the streams run before
stuttering or ending. For those that are running a long time, would you
have noticed a rebuffering instance?

Unfortunately, I'm not Perl-compliant, but I did follow the SlimServer
code as best I could and also looked at the datasheet for the
Squeezebox's MAS 35x9F-series guts. After looking around, I'm not so
sure the current implementation can really handle RTSP or SIP "live" or
"real-time" streaming. I'm also not convinced that multiple
Squeezeboxes can be truly synchronized. If this is all wrong, somebody
please correct it (and make me happy in the meantime). Here are my
reasons [careful, this is a long one!]:

"live" streaming--
Live streaming using the real-time protocols implements sender reports
to control presentation time. Effectively, the client and server
correlate "real time" at each respective end to a shared "stream time."
This information lets the server tell the client when the packet should
be played.

A problem appears when the server and client disagree with how fast
"real time" moves. Since each end uses a different crystal oscillator,
they may disagree by a few ppm. All 44.1kHz are *not* created equal.
This might not show up if the buffer size is large enough and the stream
running time is short enough. However, if the stream runs "forever" and
there is any offset, then there will eventually be buffer overflow or
underrun leading to audible stutters. A correctly implemented client
builds in a method to synchronize with the effective data rate the
server dictates (see documentation included in the StreamPlay client at
http://www.audioactive.com/download/default.htm). Some sort of
phase-lock loop is in order, either hardware or software derived. In a
perfect world, the drift between "real time" and "stream time" could be
monitored using the audio player clock as the "real time" reference, and
the players's clock could be adjusted to exactly match the server (a
true PLL).

It doesn't look like the interface to the Squeezebox does this.
Although the Squeezebox does support monitoring its clock it appears to
lack a method to pull it on-frequency. The Squeezebox only takes more
data when its buffer can use it, based on it's own internal clock. It's
up to the SlimServer to keep it filled. Since the server can only give
the Squeezebox what it has received from a streaming client, it will
either fill up it's own buffer (streaming client feeding SlimServer data
slightly faster than Squeezebox plays it) or eventually have nothing to
offer Mr. Squeeze (streaming client moving a bit slower than the
Squeezebox play rate). I don't see any mechanism in the code (or the
Squeezebox hardware) to address this problem. It looks like the best
available solution is to have the SlimServer "figure out" a timing
difference by monitoring the SqueezeBox buffer usage and adding error
concealment tricks to make the best out of a bad situation. (If
streaming live input on a good soundcard shared in the SlimServer box,
perhaps one could fine-adjust the PLL in the capturing soundcard. This
adds jitter, but it would be less audible than buffering problems or
error-concealment, but requires the SlimServer to talk back to the
recorder.)

Note that the Squeezebox works great for prerecorded files on the
harddrive or HTTP-streamed files. Being prerecorded, the "buffer" is
the whole saved file, thus automatically big enough to cover the timing
difference.

Since clocks vary between the streaming servers and the Squeezeboxes,
some will experience more problems than others. Also, since the buffer
size is fixed, higher bitrates will reveal a problem sooner for
everybody.

Multiple box synchronization--
Here, it looks like the multiple boxes only synchronize at the beginning
of a new file. At the end of a song, the SlimServer waits for ALL boxes
to playout their buffers, then restarts the next song at the same time
on each box. Thus, if you play a 2-hour mix show, the boxes only
synchronize once in the 2 hours. I would expect the players to be
noticable off at the end of the mix. I haven't had the time to follow
carefully through the "master" and "slave" parts of the code, but I
think I got the gist of it.

Conclusion--
For truly bit-perfect sound streamed over an IP network, the Squeezebox
needs a PLL referenced to incoming data. Systems that implement this
right now (Digigram EtherSound, Peak Audio CobraNet, Gibson Labs MaGIC)
aren't using the same budget as the Squeezebox. The 35x9F appears to
using incoming data as a reference, but I'm not sure network-delivered
data is stable enough to be a viable solution.

--Steven

seanadams
2004-01-12, 11:03
Steven,

The purpose of synchronization is to get within a few milliseconds, for
multi-room listening. It's not intended to perfectly synchronize the
sample clocks, eg for multi-channel recording purposes and such. We are
able to synchronize initially within 2-3ms - the error comes from
variance in software and network latency. Consider that sound travels
at about 1 foot per millisecond, so for listening purposes, the
distance between speakers/rooms will dominate. Of course, for very long
tracks there will be some drift. The system looks for a margin of
out-of-syncness and restarts the stream on a song boundary only if
needed.

Now one thing that's interesting about the mas35xx processors is that
I'm told they were originally designed to handle satellite broadcast
reception. The chip has an internal PLL which can lock on to an
incoming fixed-rate bitstream and modulate the decode speed to maintain
sync. We don't use this feature though, because a) we don't want to be
limited to constant bit-rate and b) we don't have a shared clock with
which to synchronize. We use what I think they refer to as "demand"
mode. However, we do have the ability to tweak the PLL to generate a
slightly different internal clock speed. This might be used to achieve
improved synchronization after the stream has started, but would
necessitate very precise timing measurements between clients in order
to be useful.

As you point out, there are systems (eg Gibson) which are specifically
designed to deliver near-real-time distribution over switched ethernet,
but it's really intended for a different purpose and has very critical
network requirements.

Sean

On Jan 11, 2004, at 10:34 AM, Steven L. White wrote:

> For everyone having streaming problems, I'm curious to which streams
> (thus their protocols) are working and which aren't (HTTP, raw UDP,
> RTSP
> via UDP, RTSP via TCP, SIP, etc.) and how long the streams run before
> stuttering or ending. For those that are running a long time, would
> you
> have noticed a rebuffering instance?
>
> Unfortunately, I'm not Perl-compliant, but I did follow the SlimServer
> code as best I could and also looked at the datasheet for the
> Squeezebox's MAS 35x9F-series guts. After looking around, I'm not so
> sure the current implementation can really handle RTSP or SIP "live" or
> "real-time" streaming. I'm also not convinced that multiple
> Squeezeboxes can be truly synchronized. If this is all wrong, somebody
> please correct it (and make me happy in the meantime). Here are my
> reasons [careful, this is a long one!]:
>
> "live" streaming--
> Live streaming using the real-time protocols implements sender reports
> to control presentation time. Effectively, the client and server
> correlate "real time" at each respective end to a shared "stream time."
> This information lets the server tell the client when the packet should
> be played.
>
> A problem appears when the server and client disagree with how fast
> "real time" moves. Since each end uses a different crystal oscillator,
> they may disagree by a few ppm. All 44.1kHz are *not* created equal.
> This might not show up if the buffer size is large enough and the
> stream
> running time is short enough. However, if the stream runs "forever"
> and
> there is any offset, then there will eventually be buffer overflow or
> underrun leading to audible stutters. A correctly implemented client
> builds in a method to synchronize with the effective data rate the
> server dictates (see documentation included in the StreamPlay client at
> http://www.audioactive.com/download/default.htm). Some sort of
> phase-lock loop is in order, either hardware or software derived. In a
> perfect world, the drift between "real time" and "stream time" could be
> monitored using the audio player clock as the "real time" reference,
> and
> the players's clock could be adjusted to exactly match the server (a
> true PLL).
>
> It doesn't look like the interface to the Squeezebox does this.
> Although the Squeezebox does support monitoring its clock it appears to
> lack a method to pull it on-frequency. The Squeezebox only takes more
> data when its buffer can use it, based on it's own internal clock.
> It's
> up to the SlimServer to keep it filled. Since the server can only give
> the Squeezebox what it has received from a streaming client, it will
> either fill up it's own buffer (streaming client feeding SlimServer
> data
> slightly faster than Squeezebox plays it) or eventually have nothing to
> offer Mr. Squeeze (streaming client moving a bit slower than the
> Squeezebox play rate). I don't see any mechanism in the code (or the
> Squeezebox hardware) to address this problem. It looks like the best
> available solution is to have the SlimServer "figure out" a timing
> difference by monitoring the SqueezeBox buffer usage and adding error
> concealment tricks to make the best out of a bad situation. (If
> streaming live input on a good soundcard shared in the SlimServer box,
> perhaps one could fine-adjust the PLL in the capturing soundcard. This
> adds jitter, but it would be less audible than buffering problems or
> error-concealment, but requires the SlimServer to talk back to the
> recorder.)
>
> Note that the Squeezebox works great for prerecorded files on the
> harddrive or HTTP-streamed files. Being prerecorded, the "buffer" is
> the whole saved file, thus automatically big enough to cover the timing
> difference.
>
> Since clocks vary between the streaming servers and the Squeezeboxes,
> some will experience more problems than others. Also, since the buffer
> size is fixed, higher bitrates will reveal a problem sooner for
> everybody.
>
> Multiple box synchronization--
> Here, it looks like the multiple boxes only synchronize at the
> beginning
> of a new file. At the end of a song, the SlimServer waits for ALL
> boxes
> to playout their buffers, then restarts the next song at the same time
> on each box. Thus, if you play a 2-hour mix show, the boxes only
> synchronize once in the 2 hours. I would expect the players to be
> noticable off at the end of the mix. I haven't had the time to follow
> carefully through the "master" and "slave" parts of the code, but I
> think I got the gist of it.
>
> Conclusion--
> For truly bit-perfect sound streamed over an IP network, the Squeezebox
> needs a PLL referenced to incoming data. Systems that implement this
> right now (Digigram EtherSound, Peak Audio CobraNet, Gibson Labs MaGIC)
> aren't using the same budget as the Squeezebox. The 35x9F appears to
> using incoming data as a reference, but I'm not sure network-delivered
> data is stable enough to be a viable solution.
>
> --Steven
>
>