At 23:35 04-09-2004, you wrote:
Jorge Cardoso wrote:
Hi all,
I have been playing around with [oggcast~ ]plus Icecast2 and a question has arised: What is the effect of changing the buffer size in [oggcast~]?
It would seem to me that using a bigger buffer would mean having a higher delay in the stream from to Icecast, but it seems to work the other way round! When I lower the buffer size in [oggcast~] I get higher delays in the sound stream...
Can anyone explain how this works?
The audio gets copied into the buffer and a second thread encodes and sends it. Since encoding and sending might take some time to complete the buffer needs a minimum size that depends on the speed of your machine (encoding) and the speed of the network connection (sending). Using larger buffer on a fast machine with high-speed connection should not change anything (apart from memory usage, of course). Olaf
My problem is that I want to have the minimum delay possible, because I'm using this in a remote, collaborative, interactive, event system (ufh). Basically, several users will be able to connect to a server and control visual events, on a local application, that are sent to that server. Those events are translated into sound events, that are streamed back to the user.
So, the larger the delay in the stream, the less obvious it will be for the users to relate the visual event to the sound event...
Right now, I'm getting delays in the order of 5/6 seconds, which is alot to me (I'm testing this in a local network). I'm using [oggcast~], Icecast2 and JOrbisPlayer as the streaming client.
I guess this is all a buffers problem: Icecast2 source encoder buffer [oggcast~], Icecast2 buffer, plus streaming client buffer [JOrbis]...
I can control the client buffer size, and probably the [oggcast~] buffer (if I recompile it). The Icecast2 buffer is more troublesome...besides, there are certainly efficiency problems in reducing the buffer sizes...
Has anyone tried to do something like this before? Any advice?
jc