Éditorial sonore mars 2010

Posté par  (site web personnel) . Modéré par baud123.
Étiquettes :
9
4
mar.
2010
Son
Choupa, pam, poum, twizzz ... Ce mois-ci la MAO sous Linux, comme à son habitude, fait preuve de son dynamisme et de sa pertinence en nous offrant encore une pléiade de nouvelles versions. Parmi celles-ci, on notera particulièrement :
  • SchismTracker : Beaucoup d'améliorations diverses pour ce Tracker, qui est la copie d'un grand classique (Impulse Tracker), l'a surpassé, et est devenu à son tour une référence en la matière.

  • Rosegarden : Ce séquenceur Audio et MIDI et logiciel de notation musicale mythique est maintenant basé sur Qt4 : interface graphique complètement refaite, beaucoup de nouvelles fonctions et d'améliorations d'usabilité. Cette nouvelle version marque l'aboutissement d'une ré-écriture du code qui a duré plusieurs années !

  • Guitarix : Une nouvelle fonction de taille pour cet amplificateur virtuel de guitare : le MIDI-learn, un début de support pour ladish et 7 nouveaux models d'amplis. Miam !

  • Rivendell : Reprise du code en profondeur pour un logiciel encore plus pro dans le monde professionnel de la diffusion radio.

  • QdicoRime : De nouvelles fonctions encore plus poussées pour ce dictionnaire de rimes unique en son genre.
      • Sur le site de LinuxMAO, nous accueillons un nouveau modérateur des forums : Tumulte et nous pouvons noter l'apparition de deux nouvelles pages de documentation sur :
      • Jalmus, un logiciel pour l'apprentissage de la lecture musicale. Son développeur est présent sur le site.
      • jdelay, une application de mesure de la latence d'une carte son. Logiciel ancien mais toujours d'actualité (testé avec jack2).
      Dans le monde de l'audio numérique sous GNU/Linux, notons également que le nouveau noyau Linux temps-réel (RT) (2.6.31.12-rt21) est sorti et que la Linux Audio Conference (LAC) commence à pointer le bout de son nez.

      Des mises à jour ce mois-ci pour SchismTracker, Ardour, bristol, Solfege, KMid2, common music et grace, rosegarden, jack2, mixxx, yoshimi, Frescobaldi, Guitarix, Ecasound, Rivendell, xwax, Nted, MMA, openmusic, qdicorime et denemo.

      Rendez-vous sur l'édito complet sur LinuxMAO pour plus d'informations :
      http://linuxmao.org/tikiwiki/tiki-read_article.php?articleId(...)

      Bon mois de mars en musique !

      Aller plus loin

  • # pas mal !

    Posté par  (site web personnel) . Évalué à 0.

    Cette distribution bouge pas mal ces derniers temps !

    • [^] # Re: pas mal !

      Posté par  . Évalué à 4.

      euh, ce n'est pas une distrib, mais une communauté. C'est le site de référence pour tout ce qui concerne la MAO sous Linux. Tu y trouveras toutes les bonnes infos pour faire de la MAO avec ta distrib préférée, même s'il existe bien sûr des distrib orientées MAO.

  • # Question naïve sur les noyaux RT

    Posté par  . Évalué à 2.

    Bonjour, je pose une question un peu en marge de cette news : j'ai compris l'intérêt d'avoir un noyau à faible temps de latence, voire real-time, pour la musique pro et en particulier utiliser jack ; par contre, je n'ai pas compris pourquoi par défaut le noyau n'est-il pas directement RT ? C'est donc qu'il y a des avantages dans le cas général d'avoir des noyaux non-RT, mais j'aimerais bien savoir lesquels ???

    • [^] # Re: Question naïve sur les noyaux RT

      Posté par  (site web personnel) . Évalué à 8.

      Parce que globalement un noyau real-time est un peu moins performant.

      Par défaut le noyau ne peut pas être interrompu par un thread même si celui-ci a une haute priorité. On considère que de toutes façons le traitement effectué par le noyau ne va pas durer longtemps.. sauf que pour du real-time ça peut quand même être trop long.

      L'idée c'est donc de faire en sorte que les threads de haute priorité puissent interrompre un traitement du noyau. Les mécanismes permettant ça (implémentation des spinlocks avec des rtmutexes) coûtent un peu plus cher.

      À noter aussi qu'avec un noyau real-time il faut être plus prudent. Une application qui a les privilèges pour être exécutée en haute-priorité peut bloquer le noyau si elle est mal écrite (cf [2]).


      [1] http://rt.wiki.kernel.org/index.php/Frequently_Asked_Questio(...)

      [2] http://rt.wiki.kernel.org/index.php/RT_Watchdog

      • [^] # Re: Question naïve sur les noyaux RT

        Posté par  . Évalué à 7.

        Pour compléter.
        Un noyau normal cherche a avoir la meilleure vitesse moyenne pour toutes les applications. Le temps de réponse d'une application dépend de toutes les autres applications qui tournent.
        Un noyau rt s'occupe en priorité des processus ayant une priorité rt. En théorie le temps de réponse d'une application rt ne dépend que des applications ayant une priorité rt supérieure. Bien sur cela impacte les performances des autres applications, et même du noyau comme l'a dit Sylvain.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.