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