Version imprimable
Bonjour
Je suis tout nouveau sur ce forum. Je viens ici car malgré l'aide de mon ami GOOGLE je n'est pas trouvé d'infos :calim2::?.
Je voudrais si cela existe trouver un bon tuto sur l'envoie sur un réseau local de donnée audio provenant d'un micro. Toute aide est la bien venu
Merki D'avance :ccool:
Il n'y a aucune différence en termes d'implémentation réseau que ça soit vers l'extérieur ou que ça reste dans un réseau local. Un réseau reste un réseau.
Si tu as des problèmes spécifiques avec le socket ou la récupération d'un flux audio, pose plutôt celles-là.
Tu peux chercher à partir de librairies VoIP, mais pour le reste, c'est d'abord une acquisition audio (=> librairies audio), puis un envoi réseau plus ou moins bovin des données (=> librairies de codecs audio, et système client/serveur ou diffusion réseau par UDP).Citation:
Envoyé par wild-wing
Tout d'abord merci de vos réponse
Niveau socket capture audio je me débrouille mais je ne vois vraiment pas commant on peut envoyer du son sur le réseaua bon ce genre de lib existe ? si tu a des infos sur cela je suis preneur :roll:Citation:
Tu peux chercher à partir de librairies VoIP
Ben t'as un buffer binaire d'une taille donnée, une socket => write direct dedans, avec un bout d'entête pour définir le format, la taille, le numéro de bloc et zou. Je te l'ai dit, c'est limite bovin comme truc, c'est comme si tu sauvais dans un fichier ou peu s'en faut.Citation:
Envoyé par wild-wing
Apparemment, oui, d'après une recherche très succinte : cherches "C library voip". Je n'ai pas regardé si c'était payant ou pas, mais ce serait étonnant de ne pas en trouver une gratuite.Citation:
Envoyé par wild-wing
Vu les contraintes en temps de parcours et fiabilité d'un flux audio, la QoS doit être un peu travaillé par rapport à la méthode "bovine" pour ne pas avoir de la bouilli en sortie.
Je pense qu'une petite recherche sur les librairies VoIP ne serait pas inutile.
je peux faire cela a l'aide d'une structure?Citation:
Ben t'as un buffer binaire d'une taille donnée, une socket => write direct dedans, avec un bout d'entête pour définir le format, la taille, le numéro de bloc et zou. Je te l'ai dit, c'est limite bovin comme truc, c'est comme si tu sauvais dans un fichier ou peu s'en faut.
Sous réserve de portabilité de ta structure (alignement, endianness, etc.), oui, bien entendu, pourquoi tu ne le pourrais pas ?? Ce sont des données "normales", c'est juste que c'est à toi de t'occuper de leur (dé)sérialisation, c'est tout.Citation:
Envoyé par wild-wing
Voir même pas, boost::serialize est très bien, et permet d'être portable sans se casser la tête.Citation:
Envoyé par Mac LAK
bonjour
En faite ce que je ne comprant pas c'est commant remplir la structure et apres pouvoire joué le son sur le pc distant. J'utilise openal pour la capture et j'arrive a manipuler les echantillons.
Y aurait-il une âme généreuse pourrais m'indiquer la marche a suivre?:calim2:
Faut quand même l'appeler, donc c'est bien à lui de s'en charger... ;)Citation:
Envoyé par JulienDuSud
La structure contient simplement la taille de l'échantillon, son "format" (fréquence, encodage, etc.) et tout ce qui est nécessaire pour pouvoir le rejouer de l'autre côté (=en gros, les paramètres nécessaires à la fonction de lecture).Citation:
Envoyé par wild-wing
Côté écoute, tu reçois la structure (=> tu as les paramètres nécessaires pour configurer la restitution audio), puis les samples (=> données brutes à expédier à la fonction de lecture).
Je ne vois vraiment pas où est le problème : c'est exactement comme l'acquisition audio, mais dans l'autre sens. Qu'est-ce qui te pose un souci, exactement ?
Salut
Merci Mak!!! cela marche grâce a ton explication!:ccool: mais il a toujours un mais, c'est que le traitement des donnes introduit un décalage assez important (plus d'une seconde...8O). Tu n'aurais pas une idée racourcire ce délais?
Merci encore:zoubi:!
Quel protocole de transport utilisez-vous ? TCP UDP autre ?
j'utilise le protocole UDP
Si c'est le traitement et non le transfert qui prend du temps. Il faut trouver le traitement consommateur en temps et l'optimiser.
1 seconde de décalage, c'est énorme comme temps de traitement.
salut
Ben le probleme vient du fait que je transfert toutes mes en chain de caractere socket oblige! alors il faut que je transforme mes echantillons en chaine de caractere les transmettre puis a l'arrivé les traité a nouveau. il n'existe pas des class qui découpe les chaine de caractere et qui transforme un vector en chaine de caractere?
Les sockets transfert du binaire, pas des chaînes de caractère.
Il faut juste que l'émetteur et le récepteur est la même définition du format de donné, c'est tout.
UDP est un protocole de transport (niveau 4 de l'ISO) qui supporte des flux binaires. Des protocole applicatifs (niveau 5/6/7 de l'ISO) comme SMTP ou HTTP peuvent avoir des restrictions sur le format, mais c'est au niveau applicatif, pas de la socket.
A ben ça ! tu m'apprend un truc!
Tout les tuto il n'enoyer que des chaine de caracteres. Ca veux dire que je peux remplir un buffer avec mes echantillons directement et les envoyers directement sur le réseau?
S'il n'y a pas de pointeurs dans les données et que la représentation des données est plateforme indépendante (little endian, big endian, alignement etc...) rien n'empêche l'envoyer directe.
Si l'échantillonnage ne sont que des nombres dans des bornes définis, avoir une représentation indépendante, c'est pas compliqué et peu verbeux.
Faudrait crucifier les auteurs de ces tutoriels. OK, les chaînes, c'est plus "simple", mais au moins montrer comment envoyer une structure en plus, ça ne mange pas de pain...Citation:
Envoyé par wild-wing
Comme le dit Bacelar, envoyer des données binaires, ce n'est pas bien compliqué et c'est le mode "normal" des sockets, en fait. Ce qui est compliqué, c'est quand tu ne maîtrises pas les deux points de communication, mais là, tu es dans le cas le plus simple : même architecture de machine (PC), même langage (C++) et même compilateur pour le client ET le serveur.
A condition d'avoir au moins un fichier commun entre les deux modules (le .H définissant la structure d'entête notamment), tu n'as qu'à tout balancer dans la socket sans autre forme de procès.
Tu auras le temps de te préoccuper d'un format réseau portable et adaptable quand tu en seras à un niveau plus avancé dans les communications : pour l'instant, rappelles-toi simplement que ce problème existe et qu'il n'est pas négligeable sans savoir ce que l'on fait très exactement.
En faisant ça, tu devrais déjà méchamment réduire ta latence. Ensuite, pour encore la réduire un peu plus, tu pourras introduire un buffer au niveau de la réception, et ne commencer la lecture qu'après avoir reçu (par exemple) l'équivalent d'une seconde de données audio.