Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
Notifications
< Retour vers Bidouille & Développement Informatique
Agrandir
Bidouille & Développement Informatique
Les Mains dans le Cambouis
Bidouille & Développement Informatique
Actu 1 1
Articles
Médias 33 33
Tutoriels
Forums 326 326

Sujet Le pub des programmeurs

  • 1 925 réponses
  • 117 participants
  • 119 780 vues
  • 130 followers
1 Le pub des programmeurs
Salut :coucou: y a des programeurs sur AF si oui vous bossez sous quoi ?
Afficher le premier post
141
Le multi-thread c'est pas mal aussi quand on a une appli basée sur des evenements (matériels notament). L'appli dort quand elle attend les évènements et ça c'est pas mal quand on est sous un OS multi-tâches.

Citation : t'as deja essaye de comprendre comment marchait la programmation temps reel a l'aide de plusieurs thread ? J'ai essaye plusieurs fois de bien comprendre, entre autre a l'aide du code du moteur de Jamin, mais j'ai jamais bien reussi a comprendre comment utiliser ring buffer et cie...



Pour le multi-thread je m'y suis déjà essayé mais assez peu. Je connais les mecanismes de base, avec sémaphore et accès concurentiels. Je dirais qu'il faut bien réfléchir quand on part sur du multi thread, car le débuggage est vraiment plus dur.

Donc non je n'ai jamais essayé de bien comprendre le temps réel + multi-thread.

Je viens de jetter un oeil sur Jamin. Le code source est vraiment pas mal, enfin ya beaucoup de commentaire. Quel est l'aspect qui te pose problème ? J'ai jeté un oeil dans io.c, c'est là qu'ils font leur tambouille au niveau des threads. Si j'ai bien compris, il y a 2 threads, un "temps réel" pour jack et un avec une priorité plus faible pour le moteur dsp. L'idée est d'activer le moteur dsp uniquement lorsque le thread jack à reçu suffisament de données. Ainsi les traitement audio sont fait en block et le thread jack est plus rarement interompu. Je pense que cette approche se justifie de part la complexité algorithmique des traitments DSP employés, notamment à base de la librairie FFTW. Vu que le temps de traitement d'une fft est en log(nb sample) (en gros hein...) ils est plus rentable d'effectuer une grosse fft que plusieurs petites.

Pour les ring buffers, ca à l'air un peu plus sioux car ils sont "lock free" , donc il y a une astuce pour qu'un lecteur et un écrivain puisse y accéder simultanément. Là je chercherai de la doc sur google, avec une implementation plus schématique pour bien comprendre.

Jul

142

Citation :

Je viens de jetter un oeil sur Jamin. Le code source est vraiment pas mal, enfin ya beaucoup de commentaire. Quel est l'aspect qui te pose problème ? J'ai jeté un oeil dans io.c, c'est là qu'ils font leur tambouille au niveau des threads.



Oui, c'est tout a fait le module qui me pose pb. Les generalites, je les comprend, comme toi, mais l'usage fondamental du ring buffer, je comprends pas. En fait, je comprends pas comment l'utiliser. Ca peut paraitre con, mais j'ai jamais compris comment programmer un truc qui calcule un effet par bloc de taille constante, et capable de fournir assez de samples a un autre thread, de taille elle variable (typiquement, disons que j'ai deja programme une fonction qui calcule l'effet de la mort qui tue par blocs de 64 echantillons, comment je fait pour wrapper autour un truc qui fait l'interface avec le moteur audio qui lui te donne des blocs de taille variable).
143
Pour le ring buffer, je ne sais pas comment cela fonctionne, mais si on prend
comme exemple le fonctionnement de l'ASIO, le modele ASIO fourni à chaque step d'echantillonage un buffer d'une taille fixée par configuration et attend un autre buffer de sortie de la meme taille...

Apres, rien n'empeche le moteur audio de travailler dans une résolution supérieur en taille, du moment qu'il est capable ensuite de fournir à la couche basse gérant la carte son la bonne taille de buffer...

Exemple : Si j'ai un echantillonage à 64 octets, à chaque step de la carte son , je vais recevoir 64 Octets.. Et je vais empiler ces buffers dans une pile
d'une taille définie.. sachant que je m'autorise peut-etre 4 buffers de 64 dans ma pile...

Apres, c comme un buffer tournant ou une pile à décalage... on ecrase le buffer
le plus ancien.. Apres, au moment du transfert vers la carte, on prend le buffer de 64 octets correspond au bon index...

LE tout est ensuite de bien gérer la mise à disposition des données par le moteur audio et les traitements pour eviter qu'à certains step, la carte
n'est pas de donnée audio à emettre en sortie... Ce qui peut se traduire
par un effet FLOP ou clic clac sur la sortie son (sauf si le buffer est rempli avec 0... mais bon, ca generera un blanc sur la sortie...)

Je crois qu'un élément important devient alors le lag entre le temps d'acquisition et le temps de mise à disposition des données valides

Genre : J'acquiers le buffer 300 et j'emets le buffer de sortie 260 (dans le
cas ou il faudrait 40 cycles d'acquisition pour que les effets mettent à disposition les données.. dans un tel cas, le traitement aurait 40 cycles d'acquisition pour mettre à dispo les données, donc, il pourrait traiter les données soit à chaque cycle, soit les regroupés et donc traiter ces donnnées audios en entrée via une taille variable...

Suis assez claire ?

Nicolas
144
Bon, les gars, je lance peut etre une banane à l'eau, mais on verra...

Je bosse pour une petite radio libre locale en bretagne.
Des fois, n'ayant que 5 bénévoles pour la faire tournée, si il y a un bug sur une cassette, ou sur un pc, la radio n'émet plus.

Donc, je me disais qu'un pc pourrai prendre le relai si jamais il n'y a plus de musique par ex au bout de 1 mn de silence.

On fait rentrer le signal ds le pc, et ressortir une petite programmation si jamais il n'ya pas de son à rentrer.


J'imagine que cela ne doit pas etre mortel à concevoir, mais je n'y connais absolument rien.

Auriez vous un peu d'aide à nous filer ?
145
Ok. Ca devient interressant :humm: N'est ce pas le rôle du ring buffer justement ? D'un côté le thread traitement "fixe" écirt ses blocs dans le ring buffer et de l'autre le thread traitement flottant prend ce dont il a besoin dans le ring buffer. A voir.

Bon je regarderai ça ce soir, ca me botte pas mal. Maintenant je retourne à mon vrai travail, au combien moins interessant :(

Jul

146
ROmain,
non, la détection présence audio n'est pas compliquée à faire, ni la temporisation au bout de laquelle tu estimes que le silence a trop longtemps duré.

Pense cependant que l'ajout d'un élément dans la chaine audio (un PC de secours en l'occurence) diminuera le temps de disponibilité (risque de panne supplémentaire non négligeable).

Ceci dit, si le PC n'est pas sur le trajet du signal allant vers l'émetteur, mais avant console de mélange, oui, c'est une solution interressante.
Et utilisée en milieu professionnel. :clin:

Formateur en techniques sonores ; électronicien ; auteur @ sonelec-musique.com

147
Je rappelle toutefois que temps-réel ne signifie pas nécessairement "à la microseconde" mais "au temps de réponse déterministe" (dans des limites connues). Les automates programmables industriels sont depuis longtemps multitâches et temps réel : les tâches sont cycliques la plupart du temps, nombreuses, et d'une période allant de en gros 3 à 5ms pour la tâche rapide à 100-200ms pour les tâches auxiliaires. Le temps de réponse des tâches évènementielles est de l'ordre de 100µs, tout est surveillé par des watchdogs. C'est un délice à programmer, et complètement impossible à planter, sauf à faire des boucles dont le temps dépasse le temps de tâche alloué :fleche: le bulldog arrête tout.

:coucou: Chimimic !!!

Il y a deux moyens d’oublier les tracas de la vie : la musique et les chats.
Albert Schweitzer

148
Merçi, j'ai vu chimimic, que sur ton site tu proposai un logiciel pour lire un fichier des que du son est joué, ça serai ce genre de chose, sauf que là il jouerai si il n'y avais pas de son.
149

Citation :
Je rappelle toutefois que temps-réel ne signifie pas nécessairement "à la microseconde" mais "au temps de réponse déterministe" (dans des limites connues)



Pour l'audio, on n'a pas des contraintes aussi fortes, donc la difference est beaucoup moins importante.

Tiens, du coup, je me suis motive a faire un petit prototype de faux moteur audio pour cette histoire de ring buffer. C'est pas encore pret, mais j'espere pouvoir y consacrer un peu de temps ce soir pour le faire tourner (il fait rien, teste juste l'interaction hote avec blocs de taille variable et plugin avec moteur dsp de taille fixe).
150

Hors sujet :

Citation : Je rappelle toutefois que temps-réel ne signifie pas nécessairement "à la microseconde" mais "au temps de réponse déterministe" (dans des limites connues).


Oui, mais pas seulement. Il faudrait aussi préciser que ce temps de réponse doit être adapté à la dynamique du système observé.

Si par exemple on imagine un système chargé de la régulation du niveau d'eau dans un bassin, alors un échantillonnage des capteurs de niveau toutes les 10 minutes peut parfaitement suffire pour amener à qualifier ce système de 'temps réel'.

A man, a plan, a canal : Panama