Sujet Le pub des programmeurs
- 1 925 réponses
- 117 participants
- 119 612 vues
- 130 followers
y a des programeurs sur AF si oui vous bossez sous quoi ?
miles1981
Citation : Oué enfin s'il faut faire 60 cycles pour additionner deux flottants 32 bits...
Pour les flottants, j'en sais rien, mais pour les entiers, ça marchait directement, 1 seul cycle pour une multiplication 16 bits, donc au pire 2-3 cycles pour la 32bits.
Citation : Les sharc en série 21XXX sont en 32 bits flottants. Je travaille là-dessus. C'est de la bonne petite brute des familles. Y'a des équivalents chez TI, et encore plus gros (tiger sharc, mais là le budget explose grave).
Je m'en doutais un peu, c'est dommage, mais bon, faut pas se leurrer, le flottant, ça demande un peu plus de transistors, donc plus cher obligatoirement !
Citation : Ouah l'aut comme qu'il se la donne...
Sérieusement, j'ai halluciné en regardant la FFT sur un sinus, il y avait un bruit de fond de qqs bits, donc sur 16bits, ça se voit vite ! En version maison avec mise à l'échelle à chaque itération, j'ai gagné 1 ou 2 bits. Et comme c'était de la qualité du courant électrique avec un gros 50Hz et les harmoniques après à analyser, il fallait tout de même conserver une plage maximale.
Citation : J'embauchais D'ailleurs celui qui va potasser le DSP est modo sur techniguitare... Mais envoie toujours un cv miles si tu cherches, j'ai quelques contacts...
Je pourrais envoyer un CV d'abrd, mais j'ai encore un an de thèse d'abord ;) Et ensuite j'ai des pistes à suivre pour trouver un boulot, pas forcément dans l'audio même, mais sans doute assez proche, et au pire, j'harcèlerai les gens ici :D
Plus sérieusement, c'est le genre de passe-temps que j'aime bien, mais bon, faut avoir les finances et le temps, sachant que j'hésiterai beaucoup à faire tout en FPGA - à la RME
- ou à conserver une partie sur DSP.Audio Toolkit: http://www.audio-tk.com/
nonconforme
Citation : Pour les flottants, j'en sais rien, mais pour les entiers, ça marchait directement, 1 seul cycle pour une multiplication 16 bits, donc au pire 2-3 cycles pour la 32bits.
C'est parce que l'archi est 16 bits. Ce que je voulais dire c'est qu'on ne travaille surtout pas en flottants 32 bits sur une archi 16 bits entiers. A moins de vouloir des perfs de merde. C'est ce qui explique le succès du blackfin en vidéo (quantification faible des éléments unitaires en vidéo, et comme ils sont nombreux on met un blackfin qui tourne vite).
C'est surprenant ton histoire de bruit de fond avec la fft intégrée, faudra que je me penche sur la question. Dans la mesure où je ne code pas directement sur le dsp (je supervise juste), certaines choses peuvent m'échapper.
Citation : Je pourrais envoyer un CV d'abrd, mais j'ai encore un an de thèse d'abord Et ensuite j'ai des pistes à suivre pour trouver un boulot, pas forcément dans l'audio même, mais sans doute assez proche, et au pire, j'harcèlerai les gens ici :D
Et tu feras bien !
Y'a pas grand monde en audio en France, faut faire le forcing pour passer. Je sais que Cabasse a recruté un peu, mais c'est très marginal.Citation : Plus sérieusement, c'est le genre de passe-temps que j'aime bien, mais bon, faut avoir les finances et le temps, sachant que j'hésiterai beaucoup à faire tout en FPGA - à la RME - ou à conserver une partie sur DSP.
RME fait tout de même du traitement du signal très simple avec le FPGA, et surtout de la commande et du routage de signaux.
Pour le gros calcul, le DSP reste très bien placé, à moins de partir sur une solution ASIC (mais là c'est pas trop les entreprises de l'audio pro qui peuvent se le permettre).
Affiliation : Dirigeant Fondateur d'Orosys - Two notes Audio Engineering
miles1981
Citation : C'est parce que l'archi est 16 bits. Ce que je voulais dire c'est qu'on ne travaille surtout pas en flottants 32 bits sur une archi 16 bits entiers. A moins de vouloir des perfs de merde. C'est ce qui explique le succès du blackfin en vidéo (quantification faible des éléments unitaires en vidéo, et comme ils sont nombreux on met un blackfin qui tourne vite).
Tout à fait d'accord.
Pour le coup dela bibliothèque standard, ça m'a aussi étonné. Oon peut faire largement mieux au niveau vitesse en reprogrammant en C voire en assembleur et sans trop de temps perdu. En même temps, j'espère que la bibliothèque a eu des mises à jour, parce qu'il y avait de sacrées différences.
Citation : Et tu feras bien ! Y'a pas grand monde en audio en France, faut faire le forcing pour passer. Je sais que Cabasse a recruté un peu, mais c'est très marginal.
Au départ, une thèse en audio m'avait tenté, mais la boîte préférait travailler avec un labo sous forme de contrat industriel. Ca m'a permis de voir autre chose. C'est dommage de voir à quel point la recherche en France est laissée pour compte et que certains domaines disparaissent complètement ou presque
Citation : RME fait tout de même du traitement du signal très simple avec le FPGA, et surtout de la commande et du routage de signaux.
C'est vrai qu'RME a fait dans le très "simple" au niveau TS, mais je pense qu'on peut faire tout aussi bien qu'avec des DSPs avec du FPGA si on parallélise bien. Avec un DSP, on aura 3-4 MACs/ALU qui tourneront très vite pour monter au-dessus des centaines de MFLOPS. Avec un FPGA - faut juste que je réexplore les FPU dispos dans les FPGA, si ça existe, combien ça coûte en terme de place aussi, ... -, on peut espérer paralléliser cela un peu plus tout en ayant une fréquence de fonctionnement plus basse.
Là encore, le problème c'est que les applications gourmandes sur FPGA sont surtout en virgule fixe - on reparle de vidéo, ... -, et parfois avec un DSP en //
Comme je suis libre de ce que je veux faire, je peux aussi me permettre de ne pas prendre la solution optimale pour fusionner plusieurs passions
Ce n'est pas ton cas 
Audio Toolkit: http://www.audio-tk.com/
nonconforme
Citation : Comme je suis libre de ce que je veux faire, je peux aussi me permettre de ne pas prendre la solution optimale pour fusionner plusieurs passions Ce n'est pas ton cas
chfais cke jveux !
Citation : monter au-dessus des centaines de MFLOPS
Le plus gros SHARC (celui que j'utilise) et autour des 2GFlops.
Le FPGA, c'est de la bombe, y'a pas à dire. mais si tu veux te cogner la programmation en HDL d'un truc aussi puissant qu'un DSP SHARC, et qu'au final ça te revienne au même prix, bah t'as intérêt à avoir une sacré puissance de feu côté développeurs et un paquet de machine à écouler. Et pour commencer à gagner de l'argent faut un gros paquet de machines à écouler.
Il existe des solution intermédiaires, avec des boîtes qui codent la ou les fonctions critiques en dur en FPGA (du genre ta FFT sur 1024 samples, on te met le bon nombre d'additionneurs accumulateurs pour faire le truc en un ou deux cycles max).
Affiliation : Dirigeant Fondateur d'Orosys - Two notes Audio Engineering
miles1981
Citation : Le plus gros SHARC (celui que j'utilise) et autour des 2GFlops.
Belle bête
Citation : Le FPGA, c'est de la bombe, y'a pas à dire. mais si tu veux te cogner la programmation en HDL d'un truc aussi puissant qu'un DSP SHARC, et qu'au final ça te revienne au même prix, bah t'as intérêt à avoir une sacré puissance de feu côté développeurs et un paquet de machine à écouler. Et pour commencer à gagner de l'argent faut un gros paquet de machines à écouler.
C'est sûr pour du pro, un bon DSP pour faire 90% du boulot plus un FPGA si besoin est, c'est impec, mais pour s'amuser, c'est autre chose
Citation : Il existe des solution intermédiaires, avec des boîtes qui codent la ou les fonctions critiques en dur en FPGA (du genre ta FFT sur 1024 samples, on te met le bon nombre d'additionneurs accumulateurs pour faire le truc en un ou deux cycles max).
Audio Toolkit: http://www.audio-tk.com/
cptn.io
Citation : C'est sûr pour du pro, un bon DSP pour faire 90% du boulot plus un FPGA si besoin est, c'est impec, mais pour s'amuser, c'est autre chose
Citation : Le FPGA, c'est de la bombe, y'a pas à dire. mais si tu veux te cogner la programmation en HDL d'un truc aussi puissant qu'un DSP SHARC, et qu'au final ça te revienne au même prix, bah t'as intérêt à avoir une sacré puissance de feu côté développeurs et un paquet de machine à écouler. Et pour commencer à gagner de l'argent faut un gros paquet de machines à écouler.
On touche au centre du prob.
Pour faire ce que je veux il me faut vraiment un DSP parce que y a de la FFT à tous les étages.
Je pensais aussi essayer de programmer en VHDL le Spartan 3 qui est proposé avec le projet sur la carte de développement Devlight mais qd j'ai vu la somme de boulot juste pour adapter je me suis dit que ca valait pas trop le coup.
Je pense prendre quand même le FPGA mais surtout pour apprendre, m'amuser , et pour faire toutes les fonctions annexes autre que le role d'un DSP et d'un ARM pourlesquels il me faudrait un processeur spécialisé
J'ai contacté le mec et il m'a dit que ils vont commencer le proto et les tests avec l'ARM que je souhaiterais voir intégré au projet, l'ARM926ESJ qui a un DSP intégré et une architecture ARM v5 mieux organisée nivo pipelines & trucmuches. Pour ceux qui douteraient de la capacité du truc, c'est ce qui fait tourner la plupart des téléphones hightech genre les derniers nokia, ...
La version finale du projet armadeus devrait sortir pour dans un an tout pile :D ...
Donc je vais déjà bosser sans le DSP, et après on verra ... Meme si ca me fait chier de pas avoir tout de suite ce dont j'ai besoin sous la main pour me concentrer à fond sur la mise en pratique ...
J'ai pas envie d'acheter un DSP séparé parce que je veux avoir le moins de circuit d'une part.
Perso, j'y connais rien en DSP. Le chamaleon etait itneressant, mais trop cher a l'epoque.
Citation : On peut faire du dev audio "facilement" sur ce genre de becanes ? (armadeus). Typiquement, compilo, tout ca, c'est compliquer de se construire sa propre chaine de compilation a partir d'un PC (j'ai seulement l'experience sur mon mini serveur MIPS, ou je cross compile pas mal de paquets, mais c'est sous linux, alors beaucoup plus facile evidemment).
Ba sur Armadeus, ca a pas vocation particulièrement à faire de l'audio, mais à développer du linux embarqué.
Le challenge n'est pas de pouvoir développer "from scratch", mais en qq sorte, de développer des drivers pour linux pour les CAN/CNA et les périphériques auxquels on relie.
Je veux pas utiliser les CAN proposés, j'aimerais utiliser des convertos de TI en 24bit/96khz. Ca va faire un truc de monstre à traiter.
Vous avez des conseils sur des chips wifi faible consommation mais forte émission facilement "rattachable" à ce genre de choses ??
Je vais bientot créer le site internet,et une discussion pour mon projet.
Sinon respect pour le blackfin, et le sharc, c des trucs de tueurs !!!
cptn.io
Pov Gabou
miles1981
Dr Pouet
Hors sujet : Initié dans le café du commerce au message 2849.
Voir aussi : http://recul-democratique.org
Gabou > Les machines a voter electroniques, c'est vraiment completement cretin, ca devrait etre tout simplement interdit. C'est tout simplement trop complexe et impossible a surveiller, sans compter la possibilite de fraude massive, pour un gain vraiment tres faible.
Je comprends meme pas l'interet, en fait.
Pouet > Je crois que l'argument était : dans certaines toute petites villes, il n'y a personne pour faire le dépouillement. De plus, dans beaucoup de cas le dépouillement est long alors que des machines permettraient d'avoir un résultat instantané.
Je ne fais que répéter l'argumentaire. Je n'y adhère pas vraiment, mais il n'est pas non plus complètement absurde ; donc faisons semblant d'être d'accord.
On peut facilement imaginer des solutions :
1- à chaque vote, la machine imprime un bulletin, le votant le vérifie, le met dans une urne, le décompte est ensuite systématique et comparé au vote électronique. Seul le vote papier fait foi.
2- l'état fait un appel d'offre pour avoir une conception complète d'une machine, laquelle conception est ensuite placée sous GPL.
3- l'état fait des appels d'offre auprès d'industriel pour faire fabriquer ces machines, les acheter et les installer.
4- d'autres appels d'offre sélectionnent des équipes chargées de vérifier la conformité des machines à la conception GPL prévue. Ca pourrait être aussi des fonctionnaires assermentés, voire les deux.
Ce serait un peu plus sérieux que des machines dont la conception est tenue secrète, et où la fraude est ultra-simple tout en étant quasiment indétectable...
Gabou > Y a un article fameux ecrit par je sais plus qui d'un code C simple qui fait quelque chose d'absolument indesceble en ne lisant que le code (je sais plus si c&est un des inventeurs du C, ou qqn d'autre, j'ai pas retrouve).
Ragoutoutou > Si tu as accès au code, qu'il est compilable, tu peux toujours faire tous les tests que tu veux, et éventuellement déceler les anomalies en regardant le comportement de l'application, la décompiler pour voir si le compilateur n'a pas produit un résultat différent de ce que ça devrait être,...
Pouet > Faut imposer Python ou java. Suite de la discussion dans "le pub des programmeurs".
Citation : Je suis pas sur que le probleme soit moins present. Au contraire, ca compliquerait plutot, je crois.
Je ne te suis pas là.
Tu penses que l'on peut aussi facilement cacher des fonctionnements du programme dans ces langages qu'en C ?
Sans prétendre que Python ou java rendent ce genre de manip impossible, j'ai tendance à penser qu'ils la rendent plus difficile, tu ne crois pas ?
Pov Gabou
Citation :
Tu penses que l'on peut aussi facilement cacher des fonctionnements du programme dans ces langages qu'en C ?
Je pense que c'est meme pire. Plus le langage est haut niveau, plus c'est complexe, et donc plus c'est tendu de tout controler. La securite pour un truc de vote, c'est un truc de malade, en fait, car elle doit jouer a tous les niveaux: aussi bien code, evidemment, que securisation des machines, etc...
Le probleme fondamental, en fait, c'est pas au niveau du codage, c'est pour ca que je pense pas que la question du langage soit tres importante (et donc pas super approprie pour ce thread
). Pour une machine de vote electronique, tu dois assurer la securite sur tout le process, c'est la la difficulte. Je vais prendre un exemple extreme d'un truc dont on peut supposer que c'est relativement sur: un sous marin nucleaire arme. C'est extremement controle, a peu pres personne ne sait ou il est a un instant donne en dehors du sous marin, les gars qui y sont sont entraines specialement pour ca. Pour les machines de vote, tout le monde doit y avoir acces au jour du vote, ca doit etre reprogramme a chaque fois si j'ai bien compris, il y a plein de modeles partout sur le territoire, ce qui veut dire au bas mot des milliers de personnes y ayant acces. Et surtout, le fait que ce soit informatique rend la possibilite de fraude massive (reproduite a l'identique) extrement facile. Securiser un truc pareil est ultra complexe si on veut le faire correctement...
En fait, plus j'y reflechis, plus je pense que c'est totalement et fondamentalemt cretin comme idee. Surtout aux vues de ce que ca apporte.
Citation :
Au fait, ton wrapper au-dessus de l'interface VST, ça en est où ?
Au point mort, je croule sous les projets, la, entre la these, la preparation du SOC 2007, quelques projets info oriente traitement de signal... La, je compte meme plus le nombre de WE entierement brules.
- < Liste des sujets
- Charte