réseau audio micro

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à.

Citation:

---

Envoyé par wild-wing

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

---

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).

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éseau

Citation:

---

Tu peux chercher à partir de librairies VoIP

---

a bon ce genre de lib existe ? si tu a des infos sur cela je suis preneur :roll:

Citation:

---

Envoyé par wild-wing

Niveau socket capture audio je me débrouille mais je ne vois vraiment pas commant on peut envoyer du son sur le réseau

---

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

a bon ce genre de lib existe ? si tu a des infos sur cela je suis preneur :roll:

---

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.

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.

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.

---

je peux faire cela a l'aide d'une structure?

Citation:

---

Envoyé par wild-wing

je peux faire cela a l'aide d'une structure?

---

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 Mac LAK

c'est juste que c'est à toi de t'occuper de leur (dé)sérialisation, c'est tout.

---

Voir même pas, boost::serialize est très bien, et permet d'être portable sans se casser la tête.

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:

Citation:

---

Envoyé par JulienDuSud

Voir même pas, boost::serialize est très bien, et permet d'être portable sans se casser la tête.

---

Faut quand même l'appeler, donc c'est bien à lui de s'en charger... ;)

Citation:

---

Envoyé par wild-wing

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.

---

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).
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.

Citation:

---

Envoyé par wild-wing

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?

---

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...

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.

Citation:

---

Envoyé par Mac LAK

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.

---

Salut,
J'avoue que sur ce point je serais plus sceptique. Quand effectivement on n'a jamais fait la chose avant, c'est prendre le risque de balancer un pointeur, une référence ou un objet plus complexe car à un moment on va vouloir modifier la structure en ayant oublié qu'on l'envoi telle quelle. Je préfère faire un protocole simple dès le départ quitte à l'enrichir ensuite.

Merci pour toutes ces réponse !

Mais y un truc que je ne pige pas:cry:, c'est que la fonction sendto pour les socket il faut lui rentré des char non :scarymov:? commant je fais pour envoyer mon tableau d'échantillon en binaire(je pense pas que se sois trés compliqué de passé d'usigned int vers du binaire)?

Code:

---

1 2 3

size_t sendto(int socket, const void *message, size_t length, int flags, const struct sockaddr *dest_addr, socklen_t dest_len);

---

Moi, je vois "const void *" pas "char*".

Il vaut mieux que cela soit un tableau de "unsigned int".
Faire un sendto sur pour chaque unsigned int, ce n’est pas super optimisé.:mouarf:

:calim2::calim2::calim2:c'est pas juste:calim2::calim2::calim2:

cela ne marche pas , le compilateur m'indique qu'il ne peut pas convertir le type x vers const char *
Question : si je veux lui envoyer le tableau d'échantillons je donne a sendto que l'adresse du tableau?

@bacelar : certaines machines (HP-UX de mémoire mais il y en a d'autres) on comme prototype pour sendto

Code:

---

int sendto(int socket, char message, int length, ...

---

C'est pas beau, c'est pas la norme et tout ce que tu veux, je suis d'accord mais c'est comme cela et il faut vivre avec.

Donc oui, dans certain cas, lorsque l'on veut envoyer une structure, il faut bien caster l'adresse de cette structure (ou le pointeur de cette structure) en char *

alors j'ai eu un faux espoire :ouin: donc je suis obligé de converitr tout mes samples en char * les concaténé pour créé un buffer puis utilisé sendto. y vraiment pas d'autre alternative? moi j'aimé bien le coups des donné binaire:roll:

Citation:

---

Envoyé par wild-wing

donc je suis obligé de converitr tout mes samples en char * les concaténé pour créé un buffer puis utilisé sendto.

---

Non. Je pense qu'il s'agit juste de faire une conversion de type pour le faire entrer dans ta fonction. un char* n'a pour objectif que de pouvoir adresser les octets un à un :

Code:

---

1 2 3 4 5 6 7 8

struct mon_message{ int valeur_1; int valeur_2; int valeur_3; }; mon_message msg; sendto(socket_, reinterpret_cast<char*>(&msg), sizeof(msg),//...

---

Même si je n'aime pas ce genre de chose.

Citation:

---

Envoyé par 3DArchi

J'avoue que sur ce point je serais plus sceptique. Quand effectivement on n'a jamais fait la chose avant, c'est prendre le risque de balancer un pointeur, une référence ou un objet plus complexe car à un moment on va vouloir modifier la structure en ayant oublié qu'on l'envoi telle quelle. Je préfère faire un protocole simple dès le départ quitte à l'enrichir ensuite.

---

Il a déjà été dit à l'OP de ne pas y mettre des pointeurs ou autres choses du même genre dans la structure, tout comme je lui ai dit de ne mettre que les informations nécessaires dans la structure d'entête.
Après, bien sûr, il faut aussi "compiler" toutes ces informations, c'est évident. Cela reste un problème assez simple à résoudre en général, toutefois.