Troy McClure a écrit 2213 commentaires

ouii bien sur , il n'y a pas de mauvais softs sous linux, que des mauvaises distributions

je pense que tu as du utiliser git par mégarde.

> tu te repères aux "craquements bein audibles", en effet on est pas tout à fait dans la même optique

Je me sers de mes oreilles. Mais si tu veux maintenir qu'un buffer overrun est très souvent inaudible, libre a toi. En même temps si c'était aussi simple de faire des boucles ça se saurait. Une discontinuité même tout petite dans le signal audio ça fait clic. Un saut dans la derivée première ça cloc. Une discontinuité dans la derivée seconde ça fait plop. Etc. Si t'as un casque correct ou des moniteurs corrects tu les entends.

Donc à moins de
- gros coup de chance qui fait que la valeur et les premières dérivées se raccordent
- tu ecoutes du silence
- tu ecoutes du bruit blanc,

je ne vois pas trop dans quelles circonstances un xrun pourrait etre discret.

D'ailleurs comment est-ce que jack compte ses xruns, est-ce que c'est quand le temps alloué pour une "periode" (pour reprendre le terme utilisé dans qjackctl) a été dépassé par le callback audio (et auquel cas il peut encore "ratrapper" le coup avec les periodes supplementaires si tu as lancé jackd avec plus de 2 periodes/buffer) ou bien est-ce que c'est vraiment quand il commence à envoyer de merde à la carte son ?

On entend pas forcément des Xruns de moins de 10 ms, le son est juste moins bon, voire carrément dégueu, du fait de la distortion des formes d'onde que ça engendre.

ah ? chez moi, que ce soit sous windows, mac ou linux quand j'ai un "xrun" cad un bloc qui n'a pas pu etre calculé à temps, j'ai juste un craquement bien audible , le genre de machin qui ne passe pas inaperçu. A moins que ta carte son applique encore des traitements sur les données que tu lui envoies genre un reechantillonnage ou une petite bufferisation supplementaire pour assurer le coup, j'ai du mal a imaginer dans quelles situation un xrun peut passer inaperçu.

Pour le reste je laisse tomber je crois qu'on ne pourra pas se convaincre l'un l'autre.

3ms ? A cette latence-là, pour générer une sinusoïdale simple, tu peux peut-être t'en sortir,
avec de la chance et un ou deux battements... :-}

pour le reste, genre mixer dix flux différents en temps réel (ce qui est la routine pour un synthé d'orgue par exemple), ou avoir des effets temps réel en nombre respectable ajoutés à une synthèse déjà complexe, il est impossible d'avoir une sortie fiable à moins de 30 ms de latence sur un OS standard, et il n'y a rien d'anormal à ça.
C'est juste complètement hors des spécifications d'un OS normal !

désolé mais ne suis pas du tout d'accord , j'ai testé moultes soft-synth vst/au/rtas , dont certains très gourmands en cpu, aussi bien sous windows que sous mac avec des tailles de buffers de 64 echantillons à 44100Hz (cad par chunks de 1.5ms , en comptant large on peut arrondir à 3ms ou 5ms de latence) sans problemes particuliers. ça juste marche. Dire qu'en dessous de 30ms on n'a rien de fiable , pour moi c'est du fud. Et franchement ça se saurait. Si la situation était si pourrie sous les autres OS, comment expliquerais-tu qu'aucun des editeurs majeurs de synth / sequencers et autres ne se soit precipité sur linux ?

1) une latence perceptible à l'oreille et qui donne de la mollesse au clavier

Je ne suis pas d'accord, peux tout a fait avoir une latence très acceptable (3ms par ex). 3ms, c'est le temps que met une onde sonore pour parcourir 1m c'est donc le genre de latence que tu rencontre souvent dans "la vraie vie"

2) des sautes de son occasionnelles

là ca depend de ce que tu appelles occasionnelles. Meme avec ton noyau rt si un des tes synths ou effets commence a bouffer trop de cpu ou bugger ça va chier. Y'a quand même des gens qui utilisents des laptops sur scene sous windows ou macos et qui n'ont pas de problemes. Peut-être que le gain apporté par les 0.001% de fiabilité supplémentaire ne vaut pas tous les efforts demesurés qu'il faut deployer sous linux ?


3) un manque de fiabilité qui s'aggrave avec le temps d'exécution
des logiciels

admettons, là je sais pas. J'aurais quand même tendance à dire que c'est de la faute des logiciels si leur perf se degrade quand le temps passe, non ?

linux - c'est un écosystème très riche.

ah bon ? moi j'avais plutot l'impression qu'il n'y a rien sous linux si on cherche du cote des synth ou effets natifs ? Ceux qui veulent offrir du choix passent par wine, comme le fait receptor ( http://www.museresearch.com/ )

Quand on y pense c'est quand même bien rare de tomber sur un bug de gcc (surtout les bugs du genre wrong code), si on prend en compte sa taille, sa complexité et la vitesse à laquelle il évolue, c'est surement un des logiciels libres qui a le moins de bugs !

ptet qu'il s'est contenté de suivre les instructions de http://subversion.ffado.org/wiki/StepByStepUbuntuStudio8.10R(...) qui recommandent le paquet linux-rt ?

Mais effectivement je ne comprends pas pourquoi est-ce que linux serait le SEUL os a necessiter un noyau "spécial" pour faire de l'audio dans des conditions correctes. Mac OS et windows y arrivent très bien avec leur noyau de base et leur scheduler tout pourri, alors pourquoi est-ce qu'on continue à recommander des noyaux estampillés "rt" (je n'ai même pas la moindre idée des differences qu'il y a entre ceux là et les noyau normaux) dans toutes les docs pour de l'audio ?

ou ptet que le pilote libre ati est même pas foutu de proposer le 1920x1200 sur sa radeon 3470, qui sait ? (dans l'hypothèse où il aurait un écran 24 pouces qui necessite cette résolution)

ou bien sur rapidshare, le site qui fait du fric en hebergeant des contenus illégaux.

Et pendant ce temps, le traffic internet suedois a baissé de 30% depuis le premier avril
http://royal.pingdom.com/2009/04/02/internet-traffic-dropped(...)

je trouve que le jugement manque de retractable batons

un amélioration très notable de la rapidité.

Comment se fait-ce ? Je croyais que grace au JIT le code C# était mieux optimisé en profondeur alors que le c++ qui est optimisé statiquement ne peut rivaliser ? On nous aurait bourré le mou pendant toutes ces années ?

Un journal qui ne se déballonne pas devant le lobby gnomiste, un journal salutaire.

d'ailleurs l'auteur du blog mentionné dans le journal y précise que la différence principale entre purify et valgrind , est que valgrind fait une analyse au niveau du bit (il sait, dans un mot mémoire, quels bits ont été initilialisés et lesquels ne le sont pas), alors que purify s'en tient aux bytes.

Bonjour mon Journal !

entierement d'accord avec toi, les css rigolotes et moches pour annoncer la sortie de debian ou tout autre evenement rare et ponctuel c'est bien , c'est festif , mais se trimballer une css qui rend aveugle pendant trois mois c'est juste pénible et ça fait fuir le visiteur occasionnel.

Le problème avec les administrateurs système c'est qu'ils sont au service de leurs machines, et pas de leur utilisateurs. L'utilisateur est perçu comme un element nuisible qui fait perdre du temps pour rien, et auquel il convient de pourrir la vie au maximum. Ce genre de petite brimades (fermeture de ticket avec une réponse en carton) fait partie de l'arsenal qui leur permet de mater les users recalcitrants

Enfin quelqu'un qui ose parler et dénoncer ces salopards de libristes de droite à la mentalité de profiteur étriqué qui nous spolient de notre travail, nous les gentils libristes de gauches.

Pour votre information, il parait que les libristes de droite ont plutôt tendance à preferer vim à emacs, preuve si il en est que ces gens sont définitivement nuisibles !

--
Cordialement

Merci à vous Ramón, pour ce journal qui dénonce.

Le saviez-vous : Steve Jobs, dans son infinie sagesse, a conçu les prises firewire 400 avec une forme non rectangulaire justement pour éviter ce probleme !

Cordialement,

oui mais...
everytime you jailbreak an iphone, jobs kills a kitten

En gros au lieu de faire de la musique, il signe des boiboites et organise des concours débiles sur son site

effectivement si vista n'avais pas introduit cette "super fonctionnalité" qu'est le reboot du pilote de la cg a chaud, mon poste de travail planterait trois fois par semaine, au bas mot.

(on peut aussi se dire que ce n'est pas cette fonctionnalité qui va encourager ATI a faire des pilotes moins merdiques)

Je pense que le monde se divise en deux catégories:
- les gens normaux, comme toi et moi, qui preferent lire en noir sur fond blanc
- les anormaux sombrophiles qui preferent le texte clair sur fond noir.

tu dis ça parce que tu as des petits bras