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)<p><p><p>>> 2) Sending multiple streams > - Possible to do without a server at all > - Best quality (no transcoding) > - Non-constant bandwidth > > Jean-Marc<p>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.
Hi Ulrich, <p>> 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.That's exactly what i have in mind. Perhaps we should change that to C++ to get more performance. I can also support you with coding because that's the way i want to go. Please let me know which way you go.> 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.PERFECT! That's IT. Did i say that i love you ;-)))))).> as said, speex in java is too slow for encoding more than 3 > participients, at least on the machines i tested.Let's start to port this to C++. If this is also to slow, then we build smart multi core DSP boards, running speex fast like hell and sell this for tons of dollars, so that we can buy micrsosoft in some years (Sorry, i hav my kidding day today <vbg>). Now, no kidding: Have someone ever tried to run speex on DSP's. What do you think is the adcantage? How many chanels are posible? Is CELP DSP fiendly? <p><p>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.
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.
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
--
Jean-Marc Valin, M.Sc.A., ing. jr.
LABORIUS (http://www.gel.usherb.ca/laborius)
Université de Sherbrooke, Québec, Canada
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: Ceci est une partie de message numériquement signée
Url :
http://lists.xiph.org/pipermail/speex-dev/attachments/20031121/0033822d/signature-0001.pgp