hello people, while thinking about the next little fiesta at my place, together with a friend of mine we were talking about streaming our selected music to different rooms within our location. actually it would be only two clients that would have to catch the stream. we are running one linux box which would serve the stream. the clients would be that same box and another ms windows machine. now comes my point: the whole thing would only make sense, if both clients would play the stream quite synchronously. will this be worth a try with icecast? how could the synchronization be optimized? is synchronous playing of a stream simply impossible? do we have to use the non-geeky method to just connect all our boxes to one amplifier? any other suggestions? i will get some answers tomorrow when i will give it a try with icecast, but i will be happy to get something out the list about this issue too, <p>good night, felix --- >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 Tuesday 25 May 2004 10:14, Felix Dorner wrote:> hello people, > > while thinking about the next little fiesta at my place, together with a > friend of mine we were talking about streaming our selected music to > different rooms within our location. actually it would be only two > clients that would have to catch the stream. we are running one linux > box which would serve the stream. the clients would be that same box and > another ms windows machine. now comes my point: the whole thing would > only make sense, if both clients would play the stream quite > synchronously. will this be worth a try with icecast? how could the > synchronization be optimized? is synchronous playing of a stream simply > impossible? do we have to use the non-geeky method to just connect all > our boxes to one amplifier? any other suggestions? i will get some > answers tomorrow when i will give it a try with icecast, but i will be > happy to get something out the list about this issue too, >Icecast isn't really designed for doing this. However, you could re-synchronise on the client side (using a custom client) - there's enough information in the bitstream (at least if you're using vorbis) to do this. 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.
On Tue, May 25, 2004 at 11:10:03AM +1000, Michael Smith wrote:> Icecast isn't really designed for doing this. However, you could > re-synchronise on the client side (using a custom client) - there's enough > information in the bitstream (at least if you're using vorbis) to do this.You might also take a look at jack (jackit.sf.net) which can pipe uncompressed audio over a lan fast enough for simultaneous playback, as least assuming the two systems have similar output latency. This uses a lot more bandwidth of course, but won't be significant on a 100 Mbps network. It also won't be a precise at actual synchronized playback, but you can probably tune it with delay loops if there's noticable differences in timing. I'm not sure how well supported it is on windows though, so some hacking may be necessary. See the jack.udp client at http://www.alphalink.com.au/~rd/ 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.