[icecast] About threads and bitrates and bytes...
andre.anneck at bertelsmann.de
Thu Jul 12 02:55:35 PDT 2001
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
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
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?
P.S.: If you like UML-pictures, look at the paragraph
--- >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.
More information about the Icecast