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 <p>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@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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
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@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@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@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 Ulrich,> 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 ...Yes, but this is java. You don't use any threading models and i dont know if you encode from sound card. I also don't know how optimized the code is. In my last company we have improved runtime of digital image processing routines from initially 80 seconds to 0.1 seconds. It's important to knew, which screw must be adjusted. I want to see this by my own. Perhaps you are right and there are not much improvements posible. Best regards, <p><p>Carsten --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.