Re: Streaming delays (was Raid)

["bensbarn2001" <ben_wilkinson@xxxxxxx>]

I've looked more at 1394.  It may well be possible, as you can have
225 feet max.  However to do this requires repeaters every 20' which
would be a pain and expensive (still miles cheaper than Linn 
though!).  The biggest problem seems to be that no-one has supported
products which do the streaming.  They're all geared around digital
camcorders at the moment.  1394b lookes like it gives everything I
need as it has 100m max on CAT5.  That's still being worked on at the
moment.

Next thought is to use a lossless compression algorithm (I'm looking 
at FLAC) which allows imbedded user defined fields in each block and 
would enable timing info to be stored along with the stream.  Seems
tricky, but I'll pursue that and see where it leads.

Ben

--- In ukha_d@y..., "PatrickLidstone" <patrickl@t...>
wrote:
> --- In ukha_d@y..., "bensbarn2001"
<ben_wilkinson@h...> wrote:
> > Thanks for these suggestions.  MP3 streaming is definitely
more 
> > straightforward as there is timing info in the encoding. 
However, 
> > I'd really like to be able to do this with an uncompressed 
digital 
> > stream, so as to have highest possible quality at playback. 
> > 
> > I've seen a bit of stuff on IEEE 1394 which seems to have many of
> the 
> > required features for streaming.  At least, as opposed to
TCP/IP, 
> > it's designed with that in mind.  Has anybody used/looked at
this?  
> > And is it a possibility for multiple roomed audio?
> 
> I don't think you'll be able to get the distance required for
multi-
> room transmission over a bog-standard firewire link, but, although
I 
> don't have deep knowledge of the wire format, I believe it is a 
> synchronous protocol, which bodes well.
>  
> > I also wonder what would happen if you set the buffering to zero
or 
> > nearly zero at the client end to control the delays which occur
> > there.  If the network was guaranteed fast enough
(100Mb/sec) 
maybe 
> > that would work?
> 
> It'll improve things, but you still won't get perfect 
> synchronisation. Plus, you must have CPU's with enough headroom to
be 
> capable of coping with real time decoding continously, or you will
> get drop outs.
> 
> The fundamental of synchronised, streamed audio is the ability to 
> keep multiple CPU's decoding in lock step. Ethernet is not a 
> synchronous protocol, and isn't particularly reliable (even in a 
home 
> environment). If you can find a way of accurately synchonising the
> decoders, to millisecond resolution, the problem can be solved. 
This 
> can be independent of the streaming delivery (perhaps by modifying
> the NTP service, or by some other means) -- an interesting 
challenge!
> 
> Patrick

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.