Voilà :  
 
Avec des potes on joue pas mal en réseau, sous des applis qui n'ont pas de chat vocal intégré.
 
On utilise :  

• Teamspeak :

+ multiplayer (up to 500/channel)
- son pourri
- utilise un server avec un besoin en BP énorme (7ko/s min par client, en UL comme en DL)
- inutilisable à plus de 5 en même temps (ca devient la foire pour parler)
 

• Skype

+ son génial
+ P2P une fois qu'on est loggué sur le réseau  
- pas plus de 2 à la fois
 
 
Mon idée :
Coder une appli client/server vocale :  
* On donne l'adresse IP d'un des gars qui devient le "concentrateur"...ce concentrateur récupère les IP de tt ceux qui sont connectés.
* le concentrateur initialise une chaine, qui donne :  
concentrateur --> pc1 --> pc2 --> ... --> pc n --> concentrateur
PB : la latence s'additionne, mais si on est peu, avec du dsl ou cable, ca fait pas bezef (sous les 500ms ca reste jouable)
 
Idée : un flux unique transite entre chaque pc, donc chaque pc ne reçoit que mettons 7ko/s et n'envoit que 7ko/s ...
Idée 2 : chaque pc reçoit donc la trame vocale ajoutée de tt ses prédécesseurs, et ajoute sa propre trame audio (je pars du principe qu'un flux audio c jamais qu'une trame audio, et qu'on peut ajouter 2 trames audio pour n'en faire qu'une seule
Par ex, à l'opéra, qu'il y ait un gars qui chante ou tt le coeur, ca peut tjs se coder sur une trame audio...)
PB : il faut un format audio qui permette de fusionner les trames sans trop de coût CPU ni mémoire (étant donné les applis réso qui doivent tourner derrière)
 
Une fois revenue au "concentrateur", la trame est détruite, puisque tlm l'aura eu...Et une nouvelle trame est générée...
 
Ca c l'idée de base...
 
Pour ajouter un autre utilisateur, le concentrateur n'a qu'à régénérer la chaine pour l'inclure dedans...
 
C clairement orienté pour groupe de moins de 10 utilisateurs vu l'architecture...
 
PB : je sais pas si les codecs audio libre permettent ce genre de trucs...
 
Je voudrais votre avis/vos suggestions/vos idées...

Mais si j'ai bien compris, le pc1 ne recevra pas les messages des autres non ?

si, il détruit les trames après les avoir entendu

 
non mais par exemple :
 
A dit "coucou", B dit "hello", C dit "salut" et ca va dans le sens A->B->C, selon ton système, B recevra "coucou" mais pas "salut" ... non ?

ha tu veux dire que tu envoies chaque message mais séparé ... j'avais compris que tu mélangeais chaque message dans 1

j'y avais pas pensé...
En fait il faut que ce soit le pc n-1 qui détruise la partie de la trame générée par N...

Tu veux faire un token ring audio

 
   
 
sinon tu as *bien* cherché? Je suis sur qu'il y a des projets open source qui font ce genre de choses.

ben non j'en ai pas trouvé...y'a eu un thread là dessus sur linuxfr y'a pas longtemps, et même les linuxiens parlaient de skype et teamspeak...
 
ca parlait d'un truc sous gnome (donc c mort j'en ai besoin pour des jeux windows), et des protocoles H321 ou un truc du style, et de Speex..
 
Speex c celui qui est utilisé par TS, donc c de la merde...
 
-->belgique : c l'idée...mais si t'a une autre idée d'architecture qui respecte la contrainte de bp max par client de 7ko/s en UL/DL (plus tu savates ton ping) et qui ne soit pas basée sur un server, je prend...

 
H.323 mais bon je serai à ta place je le ferai en SIP
 

J'ai été jeter un coup d'oeil sur SIP...ca a l'air client server selon les schémas...c mort donc...

Le mieux avant de se lancer là dedans c'est d'évaluer clairement les contraintes temporelles du système pour voir si c'est exploitable.

 

 
oui tu l'as bien dit, tu as jeté un coup d'oeil. J'adore ces gens qui catégorisent en 'jettant un coup d'oeil'

ben montre mois où c pas client server alors...
 
G fait plein de liens, partout y'a des servers mentionnés...y'a même une liste de servers de test...
 
Sinon apparement ca marche sans servers en utilisant des trames multicast...qui normalement sont bloquées par les switchs/routeurs, etc... non ???
 
D'après ce que j'ai pu en voir (y'a un site qui rescence les applis qui implémente SIP pour faire de la téléphonie over-IP), j'ai rien vu qui explique proprement l'architecture utilisée...Si ce n'est que je vois le mot server partout...

 
bin effectivement il y a un serveur pour le naming et le discovery mais si tu as une adresse multicast dans ton réseau le serveur ne sera utilisé que pour établir la connection sur le channel multicast.
 
Et sinon tu comptes faire de l'H.323 sans serveur?  
 

on m'en avait juste parlé...j'ai regardé ce que ct et c l'ancetre de SIP...donc on est dans le même pb...
 
Ca respecte pas 2 choses :  
- le multicast ca traverse pas le net  
- je dois pas avoir de server...

 
J'allais le dire... C'est pas vraiment du P2P sous cette optique (sic) là !

 
bin je vois mal comment c'est réalisable alors

Au départ, un pc sert de serveur, il centralise les ips et établit l'anneau, il communique ensuite à chaque station le nom de la station suivante et c'est "parti". Car c'est clairement chaud à programmer

En P2P pur ca sous entend que chaque pc envoit librement à chaque PC...ce qui fait que si ton protocole consome 5 de BP, t'a besoin de n * 5 de BP en UL et en DL...en partant du postulat que t en full duplex, et que tu acceptes de recevoir plusieurs voix en simultané...
 
Mais je vous sens captivés là, si vous avez une idée, je suis preneur...
C pas la partie connection qui me semble la plus chaude, c surtout le truc audio...vu qu'en fait le "token" contient divers trames, et qu'il faut à chauqe poste etre capable de les séparer pour savoir lequelles arreter (celle qui ont été émises par ce poste) et lesquelles transmettre...

Ce qui fait qu'au final, tu ne peux pas mixer les flux et donc tu gaspille encore plus de bande passante.
 
Tu pourrais faire un structure en anneau pour la diffusion et une architecture client-> serveur pour la réception.
 
Les stations clientes envoient leur données audio au serveur. Celui-ci mixe les flux et envoie l'information dans l'anneau qui en devient finalement plus une ligne puisque le dernier ne doit plus renvoyer le flux au serveur. Tu peux éventuellement créer plusieurs lignes de la sorte partant du serveur afin de diminuer la latence.
Au final, le serveur a besoin de pas mal de bande passante en download et de moins en upload. Reste à voir si niveau latence, ce n'est pas trop mauvais. Ce qui est pas mal c'est que si deux personnes parlent en même temps, elles parleront aussi +/- en même temps dans le flux audio mais elles le recevront décallé.

c pas con du tout ca comme idée...
 
Seulement j'y connais rien aux codecs audios, je sais pas si l'opération de "mixage" est possible...mais c clairement une bonne solution...on avance
 
C clair que si ct sur un lan, un coup de multicast, et c réglé...
 

Tu peux aussi faire ça en forme d'abre, ça diminue le latence mais augmente la bande passante nécessaire pour chaque machine.

serveur : - recevoir un flux audio par client
          - mixer les flux audios destinés à chaque client
 
si ça t'intéresse vraiment autant intégrer une équipe de dév d'un logiciel déjà existant (teamspeak), rien ne sert de tout refaire

omicron : y'a pas de solutions centralisées server gratuite et de bonne qualité (c un peu logique, la BP du server il l'ont pas gratos)
 
-->TS c pas open source, et c pas gratuit...