Listen to multiple Live Streams at once

Question

I am developing an application where I need musicians to play together and I want to have an audience listen to it. I have created my publisher clients and they can create the streams, but now I want to take those multiple streams and combine them so that you can hear the guitar, singer, etc. all together.
Is this possible, do I need to tell the server side script to combine them and create a new stream? Any help would be appreciated!
Thanks

Answer 1

I haven't used it myself, but the info on the ejamming site indicates that they're using a P2P protocol, and I suspect it's UDP based.UDP is more suitable for a use case such as this, as UDP is a lossy protocol. Additionally, the P2P nature of ejamming's application takes the trip to the server out of the picture, as the data doesn't need to bounce off the server. This reduces the time it takes to get the data from one client to another.
FMS, on the other hand, uses TCP/IP, which is a lossless protocol. Any data that doesn't make it to the server on the first trip (and in the proper sequence) has to be re-sent, which adds to latency on the stream. That, combined with encoding and transmission latency really removes reliability from an application that depends on consistently low latency. That's not to say it isn't possible, it just isn't reliable.
All that said, you might consider testing with RTMFP. RTMFP is a UDP based P2P protocol supported by Flashplayer 10 (http://labs.adobe.com/technologies/stratus/). RTMFP requires that you use a rendezvous service, and currently, the only such service is Adobe's stratus service. The word is that future versions of FMS will support RTMFP rendezvous services, but there is no official word on whether "future versions" means the next version, or a version further down the road. Of course, all of this introduces a few new considerations:
1. Each musician will need a lot more upload bandwidth, as each subscriber would need to connect to the publisher to receive the stream. For example, let's say you have 5 musicians. That means each musician needs to serve his/her stream to each of the other 4 musicians (RTMFP does not support multicast/swarming)
2. This approach doesn't satisfy the need to play the streams to a listening audience (RTMFP is not suitable for serving streams to a large audience). You'd still need to publish a stream from each musician to FMS over RTMP, come up with some sort of timecode logic to track latency, and then try to sync those streams on the playback client.
I tend to shy away from the term "impossible" (that word tends to lead to foot-in-mouth), but in this case, it seems to me that an FMS-centric solution would be less than reliable.