Streams for several parties

I've been working on this a bit.  There are a bunch of problems, though.

I've hacked up the stream code a bit, such that it mostly works sometimes
in a sense. :)  You provide the ?op=stream, and it will create a FIFO
from which it will read data and stream that data to the requestor.  So
far so good.

I experimented with creating a way to identify the stream, and then
letting more than one client read from the same one.  For instance,
?op=stream&num=0 would attach the client to stream 0.  As many clients
as you like could attach to that stream.  The problem?  Assume each client
reads only 1 byte at a time, and they perfectly alternate.  Assume there
are three clients.  You're clearing your FIFO out rapido, and the clients
will sound like they're playing the song at triple speed.

This isn't easy to solve.  I thought of putting the information into
shared memory and having each client read it from there.  One client
was the designated stream reader, and the others just took what they could
from shared memory.  That way the FIFO gets depleted only as fast as the
designated reader reads.  Unfortunately, the other side of this is that
shared memory fills only that quickly as well, so it may be that the
other clients block for a bit.  Worse, there is no good way to know when
the in memory buffer has been read, so you either have to predictively
clear the buffer (meaning all but the designated reader are guaranteed
to get crappy sound), or make the buffer enormous and do something clever
like flush it at the end of each song.  This is dumb.

So now I've moved back to giving each client its own stream, and its
own FIFO.  How to make a streaming server?  Simple.  In the front end,
I'm writing something that will feed content to the FIFO.  When you
want to attach to a stream, it will find out your client id (and therefore
your stream id) and shunt its output to your stream.

It isn't working yet, but it will soon.

There are still big problems with this, though.  One is that if the
streamer (the front end) blocks, then all of the backends block too.
That is, if one client hits pause, then all of the other clients stop
getting input until he unpauses.  If I make the streamer non-blocking,
then it will stream content much too quickly.

The real solution is to guarantee the bitrate of the content, and then
fill the FIFO at the appropriate bitrate.  This requires either reencoding,
which I'm loathe to require, or having mod_mp3 be able to read and parse
mp3's on the fly (which seems like overkill).

So that's where I am, atm.

	-- Matt

    "No splints yet invented will heal
     a lawyer's broken reputation."
     Paul O'Neil

Duke University School of Law - JD Candidate, 2005
Clerk, Hughes Inn of Phi Delta Phi
Communications Coordinator, Duke Graduate and Professional Student Council
Competing Member, Moot Court Board
Member, Parents As Law Students
Research Assistant, Professor Arti Rai