Jorge Cardoso wrote:
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]...
No, it's a Vorbis problem and in parts an Ogg problem: Ogg data packages have a fixed size and thus the smaller the bitrate of your stream the more audio (= time) fits into one package. This gives you the first delay. Vorbis puts several ogg packages into one page, here you'll get the next delay. With small streams (low datarate) this can be very high. The server has another buffer that probably adds the biggest delay.
oggcast~ always keeps it's internal buffer as empty as possible. You will just get extra delay here in case you don't have enough CPU power to encode the data in time.
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?
Use ogglive~ from http://www.nullmedium.de/dev/ogglive~/ which is made for low latency. But CPU usage is rather high and it's not possible to connect several listeners.
Ways to reduce latency:
- higher bitrate
- more channels
- higher samplerate
BTW, have you checked the latency of the player you are using?
Olaf