If you sent the audio from each source as an individual (multiplexed packetized) stream, at each source you could just not play the stream (any packets) originating from that source. Simple and Effective, but would require sending more data than mixing one version at a central location and sending that version to all conections (but that would be silly anyway due to lag). But generaly you wouldnt have more than one person talking at a time and when it happens if you are using a decent compression targeted to voices (look at the compression schemes used in digital mobile phones (both GSM & CDMA)) this shouldnt be to much of a bandwidth problem anyway
Anyways, how in the hell were they able to reverse real audio encoding?
They didn't they implemented a version of the standard RTSP/RTP protocal.
This is an open standard similar to TCP/IP standard. It just happens to be the standard that Real Player uses for its protocal.
The RTSP (Real-Time Streaming Protocol) is a standard (RFC2326) session initiation/maintenance protocol that is used by RealPlayer, QuickTime, and many other real-time audio and video players.
Slashdot Mirror
If you sent the audio from each source as an individual (multiplexed packetized) stream, at each source you could just not play the stream (any packets) originating from that source.
Simple and Effective, but would require sending more data than mixing one version at a central location and sending that version to all conections (but that would be silly anyway due to lag).
But generaly you wouldnt have more than one person talking at a time and when it happens if you are using a decent compression targeted to voices (look at the compression schemes used in digital mobile phones (both GSM & CDMA)) this shouldnt be to much of a bandwidth problem anyway
They didn't they implemented a version of the standard RTSP/RTP protocal. This is an open standard similar to TCP/IP standard. It just happens to be the standard that Real Player uses for its protocal.