On 28/11/03 1:08 pm, "Richard Dobson" <[EMAIL PROTECTED]> wrote:
>> Well, I think it is better to solve the hard problems up front. We are >> talking conferencing, not audio chat. It gets a big deal when you include >> video. If we get the framework right for audio then an audio-video >> environment is just a bigger datastream but the bandwidth gets lumpy...so >> better to ensure the bandwidth is properly considered. I am a bit of a >> tartar when it comes to what name we give. If this is audio chat protocol >> then I will shut up as it is a different problem domain. > > I have been talking about audio conferencing, not video, thats is a whole > different kettle of fish, we should try to do each the best way, and for > normal people p2p is the best way for audio. I did say conferencing, not Videoconferencing and you are clearly talking about some form of informal Audio Chat. Conferencing is quite different. It is very important to use the right name for what we talk about. > > yea 42 audio streams in total are buzzing around, but that doesnt matter as > that doesnt really have any impact on each individual client, quoting this > total stream number is irrelivant as the only impact on the client is the > total number of streams it is receiving and sending. It is far from the only impact - a p2p client is basically a server as it has to manage all the comings and goings and establish links to all who are in the conference and tell everyone when they are disengaging. Just lovely for a mobile phone client... >Also I wasnt assuming > that everyone has windows (when did I?) I was just showing a solution that > will work on 90% of client machines (if the market share figures are to be > believed), i expect there is a similar solution for Linux but I dont know > much about that sort of thing in Linux so I didnt mention that, there is no > point in not using a technology just because it is made by microsoft, lets > not turn this into some kind of silly holy war. > > Richard I agree with Jesper on this. Your post strongly implied that such a solution was 'the solution' as a means to mitigate against concerns raised. It is *so* important not to dismiss concerns using an assumption on hardware or platform. In a few years time many people will be running their windows shell on a massive server which will NOT have a local dedicated sound card to offload the audio processing to. Also remember that a mobile phone pays by the bit, so 8kbps is far more desirable than 48kbps, and these are the people just as likely to be Audio Chatting. Tim _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
