> > Unless you use client side echo removal (which ofcourse will put some > > extra burden on the client, what I'm indeed trying to avoid all along, but > > it's still a compromise). But agreed, this is one of the main advantages > > of using a direct link based conference. Again, you'll benifit the most > > (and the disadvantages will be the least obvious) if all clients have > > somewhat equal specs, while in most cases I doubt this is true for Joe > > Consumer. > > Of course not all machines will have equal specs, but if they were bought > within the last 3-5 years they will likely be plenty powerful enough for our > requirements as far as CPU power goes.
lol, sorry, richard, you have no experience what is needed to actually encode and decode data, i think ... ;-) > > > >> Ofcourse you still have to mix when you use DirectX ;) > > > > > > Playing two (or more) streams simultaneously is not mixing as far as I > am > > > concerned, so no you dont necessarly have to even mix. > > > > Ofcourse the streams are mixed, just by DirectX/ALSA/whatever instead of > > you. If your soundcard has some Direct X compatible hardware for this the > > soundcard can do the mixing. (Which is still true in many cases if you use > > a server that uses DirectX for mixing too) > > But the point is that you do not have to manually code it and in so doing do > it in the processor, using such things as directx means it is far more > optimised and will take advantage of any sound hardware (or processor > extensions such as SSE) you have to accellerate this. This is in contrast to > server mixing that will have to be manually done in the processor as it > needs to be re-encoded and retransmitted. in fact server encoding can use direct x hardware, too. why shouldn't it? > > Then we both don't know ;) But most implementations probably won't be so > > advanced, if this is even possible (and you made a good point about > > re-encoding, which I more seriously doubt you can optimize much) > > Yes the real problem is the re-encoding, not the mixing. not necessarily a problem. it can be optimized in many ways ... > > > > Because you will hear yourself echo from the other end, that is I > thought > > > what you meant, but overall I doubt syncing is something we really need > > > to > > > concentrate on or worry about too much. > > > > Out of sync mixing is *the* biggest annoyance about direct-link based > > conferencing if you ask me. Escp. when participants have severly different > > connections. I find this unbareable to work with. > > Fine but not all people find it as much of a problem as you do. and not all people agree with this statement. > > > > its a > > > modified version of your model where instead of having a single server > > > you > > > could have as many as possible which communicate with each other via > p2p, > > > but anyone who is incapable due to platform issues, bandwidth, CPU, > > > firewall > > > etc to act as a server itself connects to one of these servers, this > > > provides the benefit of more evenly load balancing the CPU/bandwidth use > > > of > > > the chat over several nodes rather than concentrating on one, provides > > > instant fall back to another server if one has problems or leaves, and > > > provides your primary benefit of being able to support dialup users or > > > simple clients like pocket pc's or people who cant go p2p because of > > > firewalls. > > > > I think my idea as decribed more at the beginning of this email and here > > are pretty much alike. Are you suggesting a persistant network or these > > servers (which is p2p I suppose) or a per-conference network? (which I'd > > rather just call clustering of the servers) > > It would just be a per chat network automatically setup from the chat > participants. > > > Do you feel such a system should be part of the "base" spec for (audio) > > conferncing or an extention? And what do you feel should be done for NAT > > traversel in person to person? In case you suggest a peristant network of > > these nodes is that what should be used for that? > > I feel this must be part of the base spec, and I dont feel a persistent > network is needed, as far as NAT traversal goes the servers will need to be > able to full traverse the NAT or firewall they have, which can be done with > UPnP (Zeroconf ?), or manual setup by a knowledgable person, but we must try > to minimize that requirement. of course it is needed to have a persistant network. and to remind again: it's needed to have video conferencing, too. ulrich _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
