streaming audio

[Chris Liechti]

Rob Brown-Bayliss <rob at zoism.org> wrote in
news:mailman.1020721811.32388.python-list at python.org: 
> On Tue, 2002-05-07 at 10:29, brueckd at tbye.com wrote:
> 
>> That might come close, but instead of syncing the play of the songs,
>> you'd be syncing the request-buffer-and-then-play of the songs, so
>> you still might end up with clients off by a second.
> 
> I was think more along the lines of the clients tell the server they
> have a sufficient buffer of the song then the when all clients are
> ready the server tells them all to play.  Sort of like "We all have a
> 3 second lead, lets go" approach.

but if one machine fails all other must wait and your party will not have 
the ambient you want :-(

i would rather send out a timecode on which each machine can sync.
syncing multiple machines clocks in ms range and more accurate is solved 
for some time (NTP, network time protocol, isn't it? i know there are some 
RFCs and linux services but haev not used one personaly)

if your stream contains absolute time markers, each machine knows when to 
play regarldess if its buffer is full or half empty, no matter if you jump 
in the programm or if you all start together.

of course the markers need to be a bit a head of time. you want a buffer 
for occasional packet retransmits or bandwith drops because of other 
network traffic. say 1 to 3 seconds? note that all machines in the net must 
have a sufficiently large buffer for that time and you might not want to 
choose it too long because when you press play you want to hear something.

(in an advanced system you could gradualy increase the ahead time to 
achieve fast play but stability in the long run. the ahead time is given by 
the server, not by the client as other "unsynchronized" streaming services 
like realplayer, quicktime etc. do)

>> If you have/write a client plugin to your music player to receive
>> multicast 
> 
> I breifly looked at multicast, but there appear to be several
> "standards" rather than a standard :o)

i think multicast is primary to lower the bandwith for multiple clients 
when using a stream. if its only local a UDP broadcast may be safe enough. 
and if you have many lost packets (with TCP or UDP) on one machine you can 
not go back and play them because you would loose sync with all the other 
machines.

>> All this is great stuff if you're looking for an interesting project
>> that'll end up being useful, but if you're mostly interested in
>> getting it done then I'd imagine that there are some pre-built,
>> non-Python, open source solutions out there that'd be easier 
> 
> I had a breif look on freshmeat and a google serach, but all I could
> find were mp3 servers and expensive hardware.

i think with your desire to not use mp3, you increase the level of this 
project. you could also take OGG or some simple compression. but compressed 
data has some advantages like reduced bandwith (or more programs on the 
same wire), reduced memory requirements (larger buffers possible), reduces 
CPU usage in some cases, if you store the compressed data on disk 6 to 12 
times more music on the same HD and more.
(you can choose very high quality compression - you won't realy hear the 
difference to an uncompressed CD...)

on the other hand truly uncompressed has the advantage of not loosing an 
entire package beacuse of a single errorous bit (without using advanced 
error detection and correction). and you will have less delay in the 
decoder, which makes it a bit (only a small bit) easier to sync diffrent 
machines.

chris

-- 
Chris <cliechti at gmx.net>