Se connecter
Se connecter

ou
Créer un compte

ou
Agrandir
Les Mains dans le Cambouis
Bidouille & Développement Informatique

Sujet Le pub des programmeurs

  • 1 925 réponses
  • 117 participants
  • 122 564 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
561
Mais le fait que les signaux audios seront traités à un plus au niveau, c'est une bonne chose ou pas ? Est ce qu'on va perdre en vitesse de traitement et gagner en stabilité (comme uns sorte de machine virtuelle ?) ?

Désolé pour ces questions de noobs :oops:
562
Je ne suis pas sûr de comprendre ta question molecule.

Mais plus la prise en charge est bas niveau, mieux c'est à mon avis. :noidea:

Sinon, après avoir lu l'article, hormis la prise en charge native du 32 bits flottants, je ne vois pas en quoi le reste va impacter nos applis MAO...

Affiliation : Dirigeant Fondateur d'Orosys - Two notes Audio Engineering

563

Citation : Mais plus la prise en charge est bas niveau, mieux c'est à mon avis



Reflexion typique du gars qui programme pas et qui laisse cette tache ingrate a ses stagiaires :ptdr:
564
Bah entre s'amuser avec les priorités sous linux ou gérer ça en dur sur DSP, je choisis le DSP. Enfin en tout cas je l'impose à mes stagiaires. :diable:

Affiliation : Dirigeant Fondateur d'Orosys - Two notes Audio Engineering

565
Oui Oui Oui, je te comprend nonconf.. :mrg:
566

Citation : Mais le fait que les signaux audios seront traités à un plus au niveau, c'est une bonne chose ou pas ? Est ce qu'on va perdre en vitesse de traitement et gagner en stabilité (comme uns sorte de machine virtuelle ?) ?


Si c'est comme pour Mac OS X, à savoir que le scheduler de l'OS devient capable de gérer des priorités temps-réel, alors oui c'est un gain important pour l'utilisateur.

Le système est alors capable de donner régulièrement la main à ces applis temps-réel. Il faut éviter d'en avoir plusieurs de lancées en même temps, mais sinon ça rend le séquenceur beaucoup moins sensible aux autres applications tournant en même temps sur la machine.

Par exemple, même si tu as un anti-virus (et même plein d'autres logiciels) qui tourne en tâche de fond, le séquenceur ne sera pas perturbé.
567
Le coup de l'anti virus, je pense que c'est quasiment ingerable, car justement ca se fout a un tres bas niveau, en interceptant surement des system calls et cie. Donc t'as un systeme noyau modifie, donc ingerable. C'est comme un mauvais driver: tu peux rien y faire, a part ne pas l'utiliser...

Vista a en effet un bien meilleur systeme audio, au moins en theorie, que les precedentes versions de windows. Du coup, il rattrape les 5 ans de retard sur linux et mac os X a ce niveau la. Le coup du bas niveau plus efficace est pas forcement vrai pour l'audio.

Le premier gros avantage, si le protocole est pas mauvais, c'est qu'il y aura plus le bordel asio et cie sous windows. Comme sous mac os x (core audio) et linux (alsa), il y aura un seul truc sous windows. Toutes les cartes audio auront ce protocole, et ca fera un soucis de moins.

Citation :
ais le fait que les signaux audios seront traités à un plus au niveau, c'est une bonne chose ou pas ? Est ce qu'on va perdre en vitesse de traitement et gagner en stabilité (comme uns sorte de machine virtuelle ?) ?



Deja, bas niveau, haut niveau, c'est pas forcement tres clair. Ce qui se passe avec vista, c'est qu'une grosse partie audio qui etait dans le kernel NT est maintenant mis dans le user space, ce qui rend le truc plus stable, et pas forcement plus lent si c'est bien fait (au contraire).

Apres, la partie non audio de vista: le scheduler de windows est historiquement assez mauvais, et windows est base sur des processus lourds, contrairement aux unix, ce qui fait que la programmation par IPC est assez lourde et peu efficace sous windows. Donc la com interprocessus est peu utilisee (y a rewire qui utilise ca), et seul le multi thread est utilisable sous windows. Et la, le scheduler pour les (kernel) thread est tres tres mauvais, avec une latence moyenne de plusieurs ms, et au pire de 16 ms.

Il y a peu de chances que ca change fondamentalement sous VISTA, le coup des processus. Par contre, le scheduler, ca peut s'ameliorer en effet. Il y a aussi les capacites a avoir un kernel a faible latence, je sais pas ce qu'il en est de windows a ce niveau la.

Un papier pas trop mal qui montre un peu les problemes rencontres sous linux pour en faire un bon OS pour l'audio au niveau latence:

http://lac.zkm.de/2006/papers/lac2006_lee_revell.pdf

Je pense que le meme types de problemes se rencontrent sous windows et mac os X, et donc que ca s'applique assez largement.
568
Sympa le lien Gabou :clin:

De ce que j'ai pu voir de part mon expérience, les temps de développement sur windows avec le format VST+ASIO et sur linux en ALSA sont quasiment identiques, pour des performances tout à fait similaires. :noidea:

Affiliation : Dirigeant Fondateur d'Orosys - Two notes Audio Engineering

569
Tout ce qui est probleme de latence est quand meme nettement mieux gere je trouve. Les developpeurs ont des problemes avec windows vis a vis du scheduling par exemple, ce sont des problemes qui reviennent assez regulierement. C'est quasiment impossible de locker de la memoire en ram, aussi.

Pas mal de problemes de cartes sons, IRQ et cie, certains problemes sont propres a windows, quand meme.

Apres, asio et alsa, pour ce que j'en ai fait, c'est assez kif kif. ALSA est pas fantastique non plus au niveau de l'API (les docs sont horribles; cela dit, j'avais fait un peu d'alsa il y a quelques annees maintenant pour interfacer matlab et ma carte son). VST, le pb numero 1, c'est la sous specification, mais je crois que la, t'es au courant des problemes de VST et des differents hotes qui implementent differement le protocole :)
570
Petite question. J'ai un programme Windows qui utilise pour tout une librairie qui fonctionne sur Windows/Mac/Linux en ayant presque pas à changer le code d'un OS à l'autre. J'aimerais savoir si il existe un moyen de compiler et de tester pour la plateforme Mac sur mon PC Windows :noidea:

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