Jørgen Elgaard Larsen
2004-Aug-06 14:23 UTC
[icecast] *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.
Michael Smith
2004-Aug-06 14:23 UTC
[icecast] *Real* real time streaming (no delay/latency)?
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
Joern Nettingsmeier
2004-Aug-06 14:23 UTC
[icecast] *Real* real time streaming (no delay/latency)?
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.
Ralph Giles
2004-Aug-06 14:23 UTC
[icecast] *Real* real time streaming (no delay/latency)?
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.
Joern Nettingsmeier
2004-Aug-06 14:23 UTC
[icecast] *Real* real time streaming (no delay/latency)?
[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.