Home of the Squeezebox™ & Transporter® network music players.
Results 1 to 2 of 2
  1. #1
    Steven L. White
    Guest

    Internet streaming / Multiple Squeezebox synching - Is itpossible?

    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

  2. #2
    Founder, Slim Devices seanadams's Avatar
    Join Date
    Apr 2005
    Posts
    2,879

    Internet streaming / Multiple Squeezebox synching - Is itpossible?

    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
    >
    >

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •