Icecast - Aug 2004 - *Real* real time streaming (no delay/latency)?

Hello

Does anyone have experience with _real_ real time streaming - i.e. with 
very little delay/latency?

I need to stream from point A to point B in near-CD quality via a 100 
Mbit network. That is easily done using icecast. But here is the tricky bit:

I want as little delay in the signal as possibble - preferrably below 50ms!

I have made a test setup encoding on and serving from an 800 MHz Pentium 
II with debian GNU/Linux, icecast 2 and IceS 2. That gave me a delay of 
1 or 2 seconds. I need it to be lower.

<p>I have seen hardware that will do the same with only a 30 ms delay. Is 
that possible at all with icecast - even on a fast machine? Has anyone 
tried it? Has anyone made measurements on it?

Bandwith is (almost) no problem. Would it be possible to avoid delay 
somehow using another format (e.g. flac)? And would that work with icecast?

Is there any other software, I should look at?

<p>I have also wondered if it would help to get a sound card with hardware
support for MP(2|3) encoding. They exist, but do anyone know of one that 
has a Linux driver? I know that it will probably need some additions to 
IceS, but I don't mind getting  my hands dirty...

Any help or thoughts would be greatly appreciated.

<p><p><p><p>A bit about my project for the curious:

I work at a student radio station. Our FM transmitter is located some 3 
km's from our studio, and right now we pay quite a lot for a analog 
leased line to transport our air signal from our studio to the transmitter.

Fortunately, there is a 100 Mbit IP network between us and the building 
on which the transmitter is located (most of the way it's actually 
gigabit). We would like to use that IP network to transport the signal 
from our studio to the transmitter.

We use the air signal from the transmitter for control listening and for 
playing around us when we broadcast from outside our studio (from dorms 
or different parts of the university). Also, we use the air signal as 
headphone feed for our announcers. All that is almost impossible with a 
huge delay on the signal (by huge I mean in the order of seconds).

Anything above 90 ms delay is useless for our purpose.

I have ad an offer on some hardware that can do the trick, but for the 
price they are asking, I could easily buy 5 or 6 top-of-the-range PC's 
with decent sound cards. Also, the PC solution would be more flexible, 
allowing us to control our RDS signal and so on.

Besides working at the radio station, I am also a graduate student at 
Dept. of Computer Science at the University of Copenhagen, so I wouldn't 
mind writing a bit of code, if it was necessary.

<p><p>Hope you can help,

<p><p>Jørgen Elgaard Larsen
IT Manager
University Radio of Copenhagen
Dennmark

--- >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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

On Thursday 05 February 2004 12:55, Jørgen Elgaard Larsen
wrote:
> Hello
>
> Does anyone have experience with _real_ real time streaming - i.e. with
> very little delay/latency?
>
> I need to stream from point A to point B in near-CD quality via a 100
> Mbit network. That is easily done using icecast. But here is the tricky
> bit:
>
> I want as little delay in the signal as possibble - preferrably below 50ms!
>
> I have made a test setup encoding on and serving from an 800 MHz Pentium
> II with debian GNU/Linux, icecast 2 and IceS 2. That gave me a delay of
> 1 or 2 seconds. I need it to be lower.
>
There are 3 points at which significant latency (other than the actual network 
latency) is added in an icecast-style configuration:
  * Encoder
  * Server
  * Client

I don't think the icecast latency is particularly large. Both the encoder
and
client latency are likely to be significant. Both can be reduced without 
great difficulty.

Encoder-side: because of the way the ogg/vorbis libraries are designed, the 
natural output gives a relatively high latency (on the order of 200-300 ms is 
typical at moderate bitrates). This is easily reduced (with the penalty being 
slightly higher bitrates) by flushing the ogg stream after each vorbis 
packet. You should be able to hack ices2 to do this very easily - just 
replace calls to ogg_stream_pageout() with calls to ogg_stream_flush(). 

Client side: does the client do any buffering? Obviously, if it does, this is 
a major contribution to latency. Make sure it doesn't do any. I don't
know
what client you're using.

I suspect < 50 ms latency will be very difficult, but ~100 ms shouldn't
be too
hard.

Mike

--- >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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

Hi,

I can get ices2/icecast2 to broadcast ogg files in a playlist to FOOBAR 
in MS-Windows (and various apps in Linux). When I try to connect in 
WinAmp in MS-Windows, I get in error.log:

[2004-02-04  21:38:39] DBUG source/source_main Client added
[2004-02-04  21:38:41] DBUG format/format_generic_write_buf_to_client 
Client had recoverable error -1
[2004-02-04  21:38:42] DBUG format/format_generic_write_buf_to_client 
Client had recoverable error -1
[2004-02-04  21:38:43] DBUG format/format_generic_write_buf_to_client 
Client had recoverable error -1

Attached is my config files (xml) for icecast2 and ices2 - am I not 
setting something correctly?
It is strange it is working on many apps in Linux & Windows, but not 
Winamp...

Regards,
Murray Saul

<p>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: icecast.xml
Type: text/xml
Size: 3410 bytes
Desc: icecast.xml
Url :
http://lists.xiph.org/pipermail/icecast/attachments/20040204/3d99edcb/icecast.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ices.xml
Type: text/xml
Size: 4184 bytes
Desc: ices.xml
Url :
http://lists.xiph.org/pipermail/icecast/attachments/20040204/3d99edcb/ices.bin

one problem apart from icecast is that tcp/ip over ethernet does not 
guarantee *when* your packets will arrive, or even in what order. 
while the chances are good that it works rather quickly, you can't 
sue anyone if it doesn't ;)
but once the network becomes congested, you are in trouble. if the 
network between your two locations is one cable, not shared, no 
hubs, it might work. but if it's part of a larger net with lots of 
background traffic, i wouldn't rely on it.

transmitting audio with low latency over networks has been a 
frequent topic on the linux-audio-dev list, because it would be ever 
so cool if it worked (think clusters of machines for huge 
synthesizers or effects racks).
there have been some suggestions on how to do it, you may want to 
search the archive at http://linuxaudiodev.org/archive.php3, but so 
far the results have been mixed :(

i can't think why you would want to use an encoded stream though. 
there's many more stages to tune for latency, and you don't get the 
original signal to your fm transmitter. why not stream the digital 
out of your radio desk? or do you have to pay per byte?

regards,

jörn

<p>Jørgen Elgaard Larsen wrote:
> Hello
> 
> Does anyone have experience with _real_ real time streaming - i.e. with 
> very little delay/latency?
> 
> I need to stream from point A to point B in near-CD quality via a 100 
> Mbit network. That is easily done using icecast. But here is the tricky 
> bit:
> 
> I want as little delay in the signal as possibble - preferrably below 50ms!
> 
> I have made a test setup encoding on and serving from an 800 MHz Pentium 
> II with debian GNU/Linux, icecast 2 and IceS 2. That gave me a delay of 
> 1 or 2 seconds. I need it to be lower.
> 
> 
> I have seen hardware that will do the same with only a 30 ms delay. Is 
> that possible at all with icecast - even on a fast machine? Has anyone 
> tried it? Has anyone made measurements on it?
> 
> Bandwith is (almost) no problem. Would it be possible to avoid delay 
> somehow using another format (e.g. flac)? And would that work with icecast?
> 
> Is there any other software, I should look at?
> 
> 
> I have also wondered if it would help to get a sound card with hardware 
> support for MP(2|3) encoding. They exist, but do anyone know of one that 
> has a Linux driver? I know that it will probably need some additions to 
> IceS, but I don't mind getting  my hands dirty...
> 
> Any help or thoughts would be greatly appreciated.
> 
> 
> 
> 
> 
> A bit about my project for the curious:
> 
> I work at a student radio station. Our FM transmitter is located some 3 
> km's from our studio, and right now we pay quite a lot for a analog 
> leased line to transport our air signal from our studio to the transmitter.
> 
> Fortunately, there is a 100 Mbit IP network between us and the building 
> on which the transmitter is located (most of the way it's actually 
> gigabit). We would like to use that IP network to transport the signal 
> from our studio to the transmitter.
> 
> We use the air signal from the transmitter for control listening and for 
> playing around us when we broadcast from outside our studio (from dorms 
> or different parts of the university). Also, we use the air signal as 
> headphone feed for our announcers. All that is almost impossible with a 
> huge delay on the signal (by huge I mean in the order of seconds).
> 
> Anything above 90 ms delay is useless for our purpose.
> 
> I have ad an offer on some hardware that can do the trick, but for the 
> price they are asking, I could easily buy 5 or 6 top-of-the-range PC's 
> with decent sound cards. Also, the PC solution would be more flexible, 
> allowing us to control our RDS signal and so on.
> 
> Besides working at the radio station, I am also a graduate student at 
> Dept. of Computer Science at the University of Copenhagen, so I
wouldn't
> mind writing a bit of code, if it was necessary.
> 
> 
> 
> Hope you can help,
> 
> 
> 
> Jørgen Elgaard Larsen
> IT Manager
> University Radio of Copenhagen
> Dennmark
> 
> --- >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@xiph.org'
> containing only the word 'unsubscribe' in the body.  No subject is
needed.
> Unsubscribe messages sent to the list will be ignored/filtered.
> 

-- 
"I never use EQ, never, never, never. I previously used to use mic
positioning but I've even given up on that too."
	- Jezar on http://www.audiomelody.com

<p>Jörn Nettingsmeier
Kurfürstenstr 49, 45138 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxaudiodev.org (Linux Audio Developers)

<p><p>--- >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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

On Thu, Feb 05, 2004 at 02:55:08AM +0100, J?rgen Elgaard Larsen wrote:
> I need to stream from point A to point B in near-CD quality via a 100 
> Mbit network. That is easily done using icecast. But here is the tricky
bit:
> 
> I want as little delay in the signal as possibble - preferrably below 50ms!
As Mike mentioned, you're not going to get this low with Vorbis. However, if
you're really able to
use a fraction of your 100 Mbps link, you can trade bandwidth for latency by
using a less
space-efficient codec. FLAC, for example, allows block sizes down to 16 samples
per channel; it
would be straightforward to write a source client that did (uncompressed) flac
encapsulation
with latency comparable to that of your sound card's buffer.

Of course that means writing some code. Don't know if you're into that.
Have you tried something
obvious like 'netcat /dev/dsp' or 'wavr - | ssh remotehost wavp
-' or the like? Those don't
provide any reconnection logic on failure but you can do that in a script, or
just manually if
your network is sufficiently reliable.

Sound servers like esd and NAS can both probably do what you want as well. And
someone should
really write a network pipe for jack, if you want another coding option.

FWIW,
 -r
--- >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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

Hi Joern,

Have a look at www.live.com

Ross Finlayson has source code available to "livecaster" which allows
you to
stream audio using the RTP protocol over a UDP pipe.  Very efficient as
there is no TCPIP overhead.

http://www.live.com/liveCaster/

If you use lc which is part of livecaster, you can send the audio in from
your MP2/MP3 encoder via stdin

At the other end you should be able to decode the audio directly using a
compatible Linux player
http://www.live.com/liveCaster/receiving.html

Cheers,

Matt

----- Original Message ----- 
From: "Joern Nettingsmeier" <nettings@folkwang-hochschule.de>
To: <icecast@xiph.org>
Sent: Thursday, February 05, 2004 5:52 PM
Subject: Re: [icecast] *Real* real time streaming (no delay/latency)?

<p>> one problem apart from icecast is that tcp/ip over ethernet does
not
> guarantee *when* your packets will arrive, or even in what order.
> while the chances are good that it works rather quickly, you can't
> sue anyone if it doesn't ;)
> but once the network becomes congested, you are in trouble. if the
> network between your two locations is one cable, not shared, no
> hubs, it might work. but if it's part of a larger net with lots of
> background traffic, i wouldn't rely on it.
>
> transmitting audio with low latency over networks has been a
> frequent topic on the linux-audio-dev list, because it would be ever
> so cool if it worked (think clusters of machines for huge
> synthesizers or effects racks).
> there have been some suggestions on how to do it, you may want to
> search the archive at http://linuxaudiodev.org/archive.php3, but so
> far the results have been mixed :(
--- >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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

[windows users can ignore this, jack is linux and macosx only atm.]

Ralph Giles wrote:
> Sound servers like esd and NAS can both probably do what you want as well.
And someone should
> really write a network pipe for jack, if you want another coding option.
there is. somebody announced a jack-over-udp client a week or so 
ago. browse the mailing list archive on jackit.sf.net to find out 
more. jo/rgen, if you are in hacking mood, i'm sure the author of 
the jack udp thingie would be interested in working with somebody 
who intends to use it professionally.

(btw, speaking of jack, ices2 has experimental jack support in the 
latest -kh snapshots. it's not yet real-time safe, but on lightly 
loaded systems it works quite well. i've been streaming the output 
of my mixing desk through a few jack apps to friends for a couple of 
days now :)

best,

jörn

<p>
-- 
"I never use EQ, never, never, never. I previously used to use mic
positioning but I've even given up on that too."
	- Jezar on http://www.audiomelody.com

<p>Jörn Nettingsmeier
Kurfürstenstr 49, 45138 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxaudiodev.org (Linux Audio Developers)

<p><p>--- >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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.