- 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.
- L'édito complet sur LinuxMAO (2 clics)
- Le message d'annonce du nouveau noyau RT (0 clic)
- Linux Audio Conference (1 clic)
- 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).
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 !

# pas mal !
Posté par Selso (page perso) . Évalué à 0.
[^] # Re: pas mal !
Posté par matli . Évalué à 4.
# Question naïve sur les noyaux RT
Posté par gato . Évalué à 2.
[^] # Re: Question naïve sur les noyaux RT
Posté par Sylvain HENRY (page perso) . Évalué à 8.
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 boq . Évalué à 7.
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.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.