[speex-dev] Server based audio merge

Ulrich B. Staudinger us at die-horde.de
Mon Nov 24 01:46:13 PST 2003



Well, i don't know if we speak of the same ... The quality is ok, but
the encoding of a PCM frame on the tested machine took 2ms, which (if
the PCM frame is 7ms in length) means the machine can only encode three
streams in realtime ... 

<p><p>Am Sa, 2003-11-22 um 03.30 schrieb Devendra Jalihal:
> CELP based coders perform poorly when you mix streams. Perhaps, we need
> a transform code or a subband code at somewhat higher rate 12-16 kbps
> that will retain the quality after transcoding and mixing. Is the speex 
> ultra-wideband based on subband coding?
> -Devendra Jalihal
> 
> 
> On Fri, 21 Nov 2003, Ulrich B. Staudinger wrote:
> 
> > Hi, 
> > been silent in this discussion for quite long ...
> > 
> > Am Fr, 2003-11-21 um 08.07 schrieb Jean-Marc Valin:
> > > There's no perfect solution to the multiple client problem. Each
> > > approach has advantages and drawbacks:
> > > 
> > > 1) Mixing at the server
> > > - Allows a constant bandwidth for every client
> > > - Allows compatibility with regular VoIP prones
> > > - Requires transcoding, even when only on person is talking
> > > - Higher bit-rate required for the general case (one speaker is talking)
> > 
> > 
> > 
> > 
> > > 
> > > 2) Sending multiple streams
> > > - Possible to do without a server at all
> > > - Best quality (no transcoding)
> > > - Non-constant bandwidth
> > > 
> > > 	Jean-Marc
> > 
> > 
> > i think 1) is definitely the way to go. 2) uses up to much bandwidth ...
> > what i did when writing an avrealy in java (man speex is too expensive
> > in java): i used 1) and mixed everything on the server by doing a simple
> > addition of the various streams on raw level and then encoding after the
> > prior decoding of course. it works very good, although it could all be
> > improved a lot. 
> > 
> > what i do : i have a session frame and all connections are bundled in a
> > session, all connections have buffers again. whenever there is data in
> > the buffer of the connection, the connection get's added to the session
> > buffer, which after mixing is wiped again, as is the connection buffer. 
> > 
> > as said, speex in java is too slow for encoding more than 3
> > participients, at least on the machines i tested. 
> > 
> > ulrich
> > 
> > --- >8 ----
> > List archives:  http://www.xiph.org/archives/
> > Ogg project homepage: http://www.xiph.org/ogg/
> > To unsubscribe from this list, send a message to 'speex-dev-request at xiph.org'
> > containing only the word 'unsubscribe' in the body.  No subject is needed.
> > Unsubscribe messages sent to the list will be ignored/filtered.
> > 
> 
> --- >8 ----
> List archives:  http://www.xiph.org/archives/
> Ogg project homepage: http://www.xiph.org/ogg/
> To unsubscribe from this list, send a message to 'speex-dev-request at xiph.org'
> containing only the word 'unsubscribe' in the body.  No subject is needed.
> Unsubscribe messages sent to the list will be ignored/filtered.

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'speex-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.



More information about the Speex-dev mailing list