The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024

Latest message you have seen: RE: Smoke Alarms


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Re: Streaming delays (was Raid)


  • To: <ukha_d@xxxxxxx>
  • Subject: RE: Re: Streaming delays (was Raid)
  • From: "Doug Hendry" <ksdhe0@xxxxxxx>
  • Date: Wed, 1 May 2002 14:13:30 +0100
  • Mailing-list: list ukha_d@xxxxxxx; contact ukha_d-owner@xxxxxxx
  • Reply-to: ukha_d@xxxxxxx

The developers of the SliMP3 network MP3 player (www.slimdevices.com) are
working on multi player synchronisation - see
http://groups.yahoo.com/group/slimp3-dev/message/2933 for more details.

Their approach allows any player to join a group or be independant so you
can have it either way at any time. Control is via IR or web interface.

Doug

-----Original Message-----
From: PatrickLidstone [mailto:patrickl@xxxxxxx]
Sent: 01 May 2002 11:05
To: ukha_d@xxxxxxx Subject: [ukha_d] Re: Streaming delays (was Raid)


--- In ukha_d@y..., "bensbarn2001" <ben_wilkinson@h...> wrote:
> Thanks for this Patrick.  It's something I hadn't considered.  Have
> you heard this effect?   I figured that with a fast LAN, broadcast
> streaming and similar client PCs, such things would be negligible.
I
> note that Imerge seem to be doing the same thing (at least using
> Ethernet to distribute music digitally to clients) so thought that
at
> least someone who might know what they're doing has been looking at
> this.

The problem isn't so much with the real time delivery of the
broadcast, but with the variation in buffer sizes at the client
device. Clients are generally designed for use over poor quality wide
area networks (e.g. internet, dialup) and take a cautious approach to
buffering data in order to provide an uninterrupted listening
experince. Consequently, lag can be of the order of seconds.
Unfortunately, the human ear is particularly good at detecting the
slightest delay/phase difference at millisecond resolution (it's how
we work out the direction sounds come from), so it's likely to drive
you potty. I suspect that exactly simultaneous delivery of audio on
multiple devices using a streaming protocol would be fantastically
difficult to achieve, because it also depends on synchronising the
decoding of the stream, and the effort involved depends not only on
the particular music content but also on other stuff like the exact
capabilities of the particular CPU doing the decoding.

As a workaround, how about having one (or more) centrally distributed
streams (via Kat5 perhaps), with local amplification, in addition to
local sited Rio's. Then select between central source or local
streaming at will. Control of the central source could be via web
browser.

Patrick



For more information: http://www.automatedhome.co.uk
Post message: ukha_d@xxxxxxx Subscribe:  ukha_d-subscribe@xxxxxxx Unsubscribe:  ukha_d-unsubscribe@xxxxxxx List owner:  ukha_d-owner@xxxxxxx
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/






Yahoo! Groups Sponsor
ADVERTISEMENT
Click Here!

For more information: http://www.automatedhome.co.uk
Post message: ukha_d@xxxxxxx
Subscribe:  ukha_d-subscribe@xxxxxxx
Unsubscribe:  ukha_d-unsubscribe@xxxxxxx
List owner:  ukha_d-owner@xxxxxxx

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Home | Main Index | Thread Index

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.