Audiofanzine a 25 ans !
Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
FR
EN
Notifications
  • Refonte graphique octobre 2025
    Refonte graphique octobre 2025
    Une refonte graphique vient d'être mise en ligne. Nous espérons qu'elle vous plaira. Merci de nous signaler tout bug ou perte de fonctionnalité ici →
  • Un cadeau d'UVI pour les 25 ans d'Audiofanzine
    Un cadeau d'UVI pour les 25 ans d'Audiofanzine
    Pour célébrer notre quart de siècle, UVI se joint à nous et vous offre le Digital Synsations Vol.1. Pour en profiter c'est par ici 👉
  • Nouveauté : Bookmark article, news ou tuto
    Nouveauté : Bookmark article, news ou tuto
    Bookmarkez un article, une news ou un tuto et retrouvez-le dans votre section "Mes signets" du menu membre.
  • 6 nouveaux annuaires
    6 nouveaux annuaires
    Luthiers, Réparateurs, Cours de musique, Studios d’enregistrement, de mastering et de répétition... Suggérez l’ajout d’une entreprise, inscrivez la vôtre ou déposez un avis.
  • Alertes disponibilité et baisse de prix
    Alertes disponibilité et baisse de prix
    Ces nouvelles fonctionnalités vous permettent d'être informé·e dès qu'un produit est disponible ou que son prix a baissé.
  • Tentatives d'arnaque dans les petites annonces
    Nous faisons face depuis quelques mois à une recrudescence de tentatives d'arnaques dans les petites annonces. Suivez nos recommandations >
Bidouille & Développement Informatique
News
Articles
Médias
Forums
Tutoriels

Le pub des programmeurs

  • 1 927 réponses
  • 117 participants
  • 131 745 vues
  • 130 followers
Sujet de la discussion Le pub des programmeurs
Salut :coucou: y a des programeurs sur AF si oui vous bossez sous quoi ?
Afficher le sujet de la discussion
126
Merci pour ce lien, Wolfen, il m'interresse bien aussi !

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

127

Hors sujet : Je t'ai pas vu toi les deux premiers jours à l'AES :((( En plus Nonconforme et moi on a présenté un truc (voir dans les news AF Ellipse Audio Torpedo).

Développeur de Musical Entropy | Nouveau plug-in freeware, The Great Escape | Soundcloud

128

Hors sujet : Je suis désolé, j'avais bien prévu d'y aller. Mais j'étais et suis encore malade... :|

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

129

Hors sujet : Arf merde, bon ben bon rétablissement :clin:

Développeur de Musical Entropy | Nouveau plug-in freeware, The Great Escape | Soundcloud

130
:up:
131
Tiens je connaissais pas cette section des forum :8O:
Je sousigné Zip, Pit et Pat les pingouins suis programmeur :boire:
1 cm
132
:boire:

:up:

Quelqu'un connais REALBasic ? c'est comment ?
133
J'chais pas. Mais Visual Basic 2005, c'est pas mal...

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

134
.Net is good for you

Au cas ou vous ne le sauriez pas :

Visual Studio Express permet d'avoir gratuitement un environnemnet de
developpement C#, VB.Net etc...

Il suffit d'aller sur le site de MicroSoft et de telecharger gratuitement
ces versions...

Les seules différences se situent au niveau des outils disponibles
(integration gestionnaire de version CVS, sourcesafe absentes) et quelques
outils liés aux générations de classe (type XSD.exe ;)

Donc, on peut enfin faire du dev .Net sans RIEN PAYER et en ayant quasiment
TOUTES les fonctionnalités.. (en tout cas, aucune restriction par rapport
aux fonctionnalités du FrameWork 2.0)


Voila.. enjoy it ;)

THe Monz, Toulouse
135
Je suis aussi vrai faux programmeur a mes heures perdues, parce que j'en ai besoin pour ma recherche (je suis en these), et parce que c'est rigolo de temps en temps. J'ai pas mal ralenti recemment a cause de ma RSI.

Donc les langages, c'est essentiellement C et matlab, et recemment, je suis passe a python pour remplacer au fur et a mesure matlab qui me saoule de plus en plus de par ses capacites de programmation limitees.

En ce moment, c'est du python pour de l'apprentissage statistique
136
Salut les gens,

Bah moi, c'est plutot du C++ et du C. Avant je programmais des jeux (enfin des "bouts" de jeux). Récemment j'ai programmé un petit raytracer pour voir comment ça marche. Mais bon j'ai décidé de me concentré sur la musique pour mes loisirs, donc je programme pour la musique. J'ai regardé ce qu'il se passe sous linux et il y a des trucs interressants. De plus, tout est open source, donc on peut regarder sous le capot pour voir comment ça marche. Parfois ça fait un peu peur quand on voit la tronche du code, mais c'est très instructif. Du coup j'ai commencé à bidouiller un synthé virtuel dssi, c'est le vsti local, comme ça pour voir. C'est marrant, je me suis replongé dans le traitement du signal sous un jour nouveau bien plus enthousiasmant que mes précédents cours ! D'ailleurs j'ai découverts le site music DSP avec pas mal d'info pour programmer toute sortes de traitement : www.musicdsp.org

A vos claviers !

Jul

137

Citation :
D'ailleurs j'ai découverts le site music DSP avec pas mal d'info pour programmer toute sortes de traitement : www.musicdsp.org



Yep, c'est un tres bon site, surtout la Mailing list qui est encore tres active, avec pas mal de gens super competents. On en apprend tous les jours !

> jujupauty: 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...
138
Euh juste un petit mot sur la programmation multiThread...

En temps de calcul, ce n'est pas plus rapide que du mono Thread...

LE seul interet, est qu'on peut avoir des taches qui sont "effectuées" en
parallèles (vrai parralèle seulement sur machines multi-processeurs)...

Je dirais meme qu'en théorie, Le multiThread, c'est plus lent que le mono
dans la mesure ou l'OS doit basculer entre plusieurs thread et donc sauvegarder
le contexte, le restaurer, (pile d'appel, etc...)

Maintenant, on fait du multiThread quand on estime que plusieurs accès concurrent vont avoir lieu en meme temps...

Un Thread prioritaire sur le traitement audio et un thread d'IHM moins
prioritaire, comme ca, on peut "espérer" garantir le max de CPU pour le
thread prioritaire...

Cela dit, petit rappel : Windows n'est pas Temps reel.. et linux, non plus
à moins d'utiliser des versions spécifiques adaptés au temps réel...

Maintenant, moi , ce que j'en dis ;)

THe Monz, Toulouse
139
Salut,

Pour ma part, C++, Java (notion) et VB.
140

Citation :
Maintenant, on fait du multiThread quand on estime que plusieurs accès concurrent vont avoir lieu en meme temps...



C'est plutot courant en audio, les acces concurrents :). Et surtout, le thread calcul doit eviter tout appel systeme pour eviter de basculer en mode kernel (ca, c'est vrai sur mac, windows comme linux), cad pas de malloc, pas de primitives synchronisation, encore moins de fonctions relatives aux IO.

Citation :
Cela dit, petit rappel : Windows n'est pas Temps reel.. et linux, non plus
à moins d'utiliser des versions spécifiques adaptés au temps réel...



Correctement patche, en version "normale" (cad pas RTlinux avec tous les desavantages que ca a), linux peut garantir des latences de l'ordre de la microseconde pour des applis correctement concues. Les constructions pour faire de l'audio temps reel sous linux, ca devient sacrement costaud (voire par exemple le design de Jack, qui tourne d'ailleurs sous OS X aussi), avec des fonctionalites telles que des ring buffer "lock free" pouvant etre accedes par plusieurs thread (un writer/un reader) sans besoin de semaphores, de variable conditionnelle, etc... Des mecanismes "secure" pour garantir qu'une partie critique de la memoire sera jamais swapee, etc... Des classes speciales temps reel pour les thread.

Mais ca depasse malheureusement mes competences (l'utilisation des ring buffer dans le moteur multi-thread de Jamin me depasse totalement, par exemple).
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