View previous topic :: View next topic |
Author |
Message |
Anonymous Guest
|
Posted: Fri Aug 26, 2005 9:12 pm Post subject: Low lantency streaming for local area networks |
|
|
Dear icecast community,
some friends and I are organizing lanparties. On the last events there were complaints about sound coming out of the speakers in our location.
Unfortunately this is necessary if you want to show a movie on the beamer for example.
My idea was now to connect the DVD-player, spectating PC, whatever to the line-in port of a streaming server and distribute the sound via icecast. This has the big advantage that we can show a movie on the beamer and every person which wants to hear the sound of the movie simply has to connect to the streaming server.
I tried this configuration with ices2, icecast2 and my old SB Live! It works perfect and the quality (at level 5) is very good (ogg-format is used). Unfortunately there is a lag of 2 - 3 seconds between the input signal and the playback on my winamp.
As I've read on other websites this lag is mostly caused by the streaming client.
Is there any way to bring this latency to a level where it can be used the situations described above.
Best regards |
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Fri Aug 26, 2005 9:32 pm Post subject: |
|
|
The smallest lag you can get at the moment is setting burst-size to 0 in icecast and reducing the prebuffer size to the smallest value. eg if the bitrate is around 160kbps ie 20kbytes/s then a winamp 64k pre-buffer will be about 3 seconds lag. 20kbyte prebuffer will be around 1 second.
General rule of thumb, make burst-size in icecast and pre-buffer size in the player the same.
karl. |
|
Back to top |
|
|
laila Guest
|
Posted: Tue Oct 18, 2005 6:33 pm Post subject: |
|
|
i have almost the same probleme a 30 sec lag altough i put prebufering to 0 ms in winamp and burst size to 0 it didnt help.
can somebody help me with that please ? |
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Tue Oct 18, 2005 7:47 pm Post subject: |
|
|
laila wrote: |
i have almost the same probleme a 30 sec lag altough i put prebufering to 0 ms in winamp and burst size to 0 it didnt help.
can somebody help me with that please ? |
Any information about what you're running ? stream format etc?
karl. |
|
Back to top |
|
|
Anonymous Guest
|
Posted: Tue Nov 15, 2005 3:13 pm Post subject: |
|
|
I have the same problem, I'm using Debian Sarge, with Ices2 to record from an ALSA input i.e. the microphone socket. This is sent to Icecast2 and streamed to another machine on the network. I've tried setting the burst size to 0 and the client is not buffering the audio, but I get a 20 second delay on from audio source to it being played on the client. |
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Tue Nov 15, 2005 3:53 pm Post subject: |
|
|
Setting the burst size to 0 means that icecast will send the latest block of stream data and ices should be sending the stream as soon as it's encoded, so the 20 seconds would have to be mainly added by the player. It's not clear what player is being used and what stream settings your have configured so we can't advise on that part. The player will have to buffer if only to make sure it gets a block to decode, so a 0-valued setting for a pre-buffer may be ignored by the player.
karl. |
|
Back to top |
|
|
Guest
|
Posted: Tue Nov 15, 2005 4:08 pm Post subject: |
|
|
The player that I'm using is slimserver, I have a SqueezeBox2 from slim devices that I'm streaming to. The buffer on the SqueezeBox never goes above 2% and sits at 0% for the majority of the time. If I kill IceS2 then the stream stops immediately on the Squeezebox, I guess this means that the delay is actually in the encoding from the ALSA source to ogg by IceS2?
Also to confirm the delay I've tested the stream with VLC on my iBook and that has the same issue.
The machine that is doing the encoding does not appear to be over-loaded, the CPU hits at most 42% and generally sites at around 15%-20% whilst streaming according to top and has a load average of 1.14 |
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Tue Nov 15, 2005 5:08 pm Post subject: |
|
|
I've never heard of slimserver, but from a quick google search it looks like a streaming server app. The more apps you add into the chain the more the latency will be but without knowing what these apps are doing it's hard to say how to reduce the latency.
karl. |
|
Back to top |
|
|
Anonymous Guest
|
Posted: Thu Nov 17, 2005 10:59 am Post subject: |
|
|
I understand that adding more apps will add to the latency, but I have been able to prove that the latency is not actually being caused by the clients. I can replace slimserver with any other client (XMMS, rythmbox, VLC etc) and I still get the 20 second delay. Killing the stream at the server end results in instantaneous dropout on any client, this implies to me that the clients are definetely not doing any buffering.
Where I think the problems lies is with IceS2 whilst I assumed there should be some delay between converting the incoming PCM/Wav data from a line-in on an ALSA supported sound card to Ogg I would not expect it to take around 20 seconds and was wondering if there might be some kind of buffering being carried out by IceS2 as the cpu isn't stressed and changing the quality from stereo 44100Hz to mono 22050Hz doesn't affect the delay that I am experiencing.
I gather that IceS2 is a part of the Icecast project, if I'm wrong and I should be asking elsewhere please let me know. |
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Thu Nov 17, 2005 2:43 pm Post subject: |
|
|
ices 2 does have buffering but that is to allow for stalls in the network link to icecast, if the CPU isn't busy and the network is fine then those buffers won't apply, especially if you talking 20 seconds lag. Besides the listener, the only other place that springs to mind is a 2.2.0 bug which could affect the new listeners burst amount, 2.3 fixed that which is why I ask about what was been run. If 2.2.0 is being used then a source reconnect will clear it out.
karl. |
|
Back to top |
|
|
|