[icecast] About threads and bitrates and bytes[]...

[andre anneck]

Hi people,

I would like to ask you guys about this little method I am using to 
scale my application better. Since you have way more expirience in the 
streaming sector than I do I would like to get feedback on my thoughts.

As I said I am working on my own little streaming server, also GPL but 
java based. Now the juice:

The application is multithreaded, implementing a producer-bus-consumer 
pattern. In my case I have:

producer: A source that reads byte[] from a file, and extra mp3 stuff
bus: A channel that distributes byte[]'s to consumers
consumer: A listener that sends the byte[]'s it receives to any client, 
e.g. a tcp connect to xmms client

Now... since I am sending MP3's I can read the bitrate, thus I get the 
byte[] size I would need to
send in 1 sec to fullfill the bitrate the stream needs to play.

mp3 file with 160 kbit encoded needs 20 KByte/s:
[(160/8) * 1024 = 20 KByte]

Once the producer (which reads a local mp3 file) did read enough byte[] 
from the file (buffer=20KB) and send them to his bus, he waits the 
difference in time he has until 1 sec is full. Thus effectivly sending 
20 KByte/s.

So far this results in the producer to sleep for ~975 ms (transportaion 
of byte[] through bus taking ~25ms), thus I have an Idle thread running 
around. The ~25ms per producer would allow me to serve 40 producers 
(1000ms/25ms) with one server. This number seemed to be far too low, so 
I thought about a way to increase idle time for the producers.

I came up with this idea and would like to know what you guys think 
about it:

I have 2 ways the byte[] actually needs to take:
1) The way through producer-bus-consumer (within my control)
2) The way through the network to the client (out of my control)

I thought that it would be possible to transport more than needed per 
second byte[]'s through the p-b-c pattern but still maintain the needed 
bitrate (lower speed). I introduced a load_factor that multiplies the 
buffersize and the sleep-time of the producer. Resulting in the producer 
thread to read the KBytes he needs for the (bitrate * load_factor) and 
then wait the difference in time until (1 sec * load_factor) is full.

This now creates Idle times for my producers of ~975ms*load_factor. ;)

Thus I am lead to believe that I could scale very well and serve 
considerably more than 40 producer. What do think, is there a flaw I 
can't see? How does icecast do it?

Take care,

Andre

P.S.: If you like UML-pictures, look at the paragraph 
Architecture/Design on
http://jcast.sourceforget.net/

--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to 'icecast-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.