Vous possédez une carte 3D ATI et voulez utiliser un noyau Linux-rt ?
Ca peut être le bordel. En effet, fglrx a besoin d'être patché ( http://ubuntuforums.org/showthread.php?t=756236 HOW TO fglrx on a real-time kernel )
Là ou c'est amusant, c'est que le patch consiste à faire passer ce driver pour un driver GPL.
Pour ceux qui ne le savent pas, le noyau Linux expose certaines API uniquement aux drivers GPL. La raison de cette horreur : http://www.kernel.org/pub/linux/docs/lkml/#s1-19 Pour autoriser certains développeurs à interdire l'accès à leur code aux drivers propriétaires.
Alors, je pose la question : La GPL, licence PRIVATRICE ?
Journal fglrx on a real-time kernel
23
avr.
2009
# Privatrice ?
Posté par zebra3 . Évalué à 10.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# Tu sais lire l'anglais ?
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 10.
Il est clairement expliqué pourquoi c'est comme ça.
La GPL interdit de lier du code non GPL-compatible à elle-même (oh que je parle mal, mais bon vous m'avez compris).
Un module du noyau Linux et donc directement lié au code GPL. Il ne serait donc pas possible de charger de drivers incompatibles avec le GPL...par exemple un driver proprio.
Linus dit qu'il a explicitement indiqué une exception pour que du code proprio puisse être exécuté en tant que module. Sauf que c'est exception n'est indiqué que de lui et il ne peut pas parler pour tous les développeurs du noyau.
La directive GPLONLY, par défaut, interdit de linker avec un module non GPL.
Si un ou plusieurs développeur noyau veut autoriser une exception pour linker avec un module proprio, ben y'a tout ce qui faut dans le noyau pour le faire. Il peut suivre Linus ou pas, c'est comme il veut, sachant que c'est une exception !
Ceci a été fait, je pense, pour que le noyau se répande plus vite... Linus a une philosophie OpenSource avant tout, pas forcément Libre. C'est pas RMS.
Bref, estime-toi au contraire heureux, qu'il est autorisé cette exception pour faire tourner ton "beau" driver proprio ATI.
On peut également en conclure que le patch qui consiste à faire croire que le driver est GPL de manière à lui autoriser de taper une API GPL de manière directe dans le noyau est illégal au regard de la GPL. En effet l'entreprise, le développeur, bref l'entité ayant établi le code et l'API dans le noyau souhaitait un respect à la lettre de la GPL et c'est son choix et son droit.
Ça revient à linker du code prorio avec du code GPL sans autorisation explicite. Tu cautionnes ça toi ?
(Sans compter le fait que tu modifies le code du driver fglrx, et je ne pense pas que tu es le droit non plus...)
[^] # Re: Tu sais lire l'anglais ?
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 3.
Désolé...
[^] # Re: Tu sais lire l'anglais ?
Posté par zebra3 . Évalué à 5.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Tu sais lire l'anglais ?
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 4.
D'ailleur je cite l'auteur du poste du forum :
[quote]Fortunately, there's a fix. Whether or not this fix is legal can be disputed, but as far as I can see I don't think anyone is going to run into legal issues[/quote]
Ça ressemble à un mec qui fait l'autruche ça. Il sait que c'est illégal mais en gros il dit : personne va te poursuivre alors vas-y petit gars.
[^] # Re: Tu sais lire l'anglais ?
Posté par Guillaume Knispel . Évalué à 7.
Bref c'est totalement légal sur son propre système de pratiquer n'importe quel hack visant à faire faire n'importe quoi à un programme que l'on a acquis sous licence GPL (du moins si c'est illégal ça n'est PAS du fait de la GPL mais éventuellement d'une autre licence qu'on ne respecterait pas)
[^] # Re: Tu sais lire l'anglais ?
Posté par grid . Évalué à -2.
oui et toi ?
Moi je lis To allow choice for developers who wish, for their own reasons, to contribute code which cannot be used by proprietary modules.
Que je traduis par :" Pour autoriser les développeurs qui voudraient, pour des raisons leur appartenant, contribuer à un code qui ne peut pas être utilisés par des modules propriétaires".
>Bref, estime-toi au contraire heureux, qu'il est autorisé cette exception pour faire tourner ton "beau" driver proprio ATI.
De 1, c'est pas mon driver.
De 2, ATI, c'est de la merde, surtout sous linux
de 3, moi, qui ne sait pas lire l'anglais je lis "During the 2.4 series, a new export directive EXPORT_SYMBOL_GPL was added.", je n'ose pas te le traduire, Donc, ce symbole a été ajouté bien après l'autorisation de link des modules. Donc, là aussi tu te gourre dans la traduction.
>Ça revient à linker du code prorio avec du code GPL sans autorisation explicite. Tu cautionnes ça toi ?
oui, je cautionne, d'ailleurs, je respecte la GPL puisque je ne redistribue pas le module une fois compiler. je ne respecte pas la licence d'ATI, mais encore une fois, JE N'AI AUCUN PROBLEME DE CONSCIENCE à modifier et à compiler pour que cela fonctionne.
[^] # Re: Tu sais lire l'anglais ?
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 3.
Ta traduction est juste mais ton interprétation est fausse. C'est l'exception qui est laissée à la discrétion des développeurs. C'est pas la GPL qui est privatrice. Maintenant si tu le souhaites on peut revenir au vieux troll GPL versus BSD, mais là on parle du noyau Linux, il est en GPL, si ça te plait pas tu peux toujours utiliser un autre noyau, ou un autre OS.
Si t'aime pas ATI et que tu trouves que c'est de la merde sous Linux pourquoi tu essayes de l'utiliser et pourquoi tu viens en parler ici ? D'autant que j'ai jamais dis ni que c'était un driver bien, moyen ou mauvais, ni parlé du matos.
Pour le EXPORT_SYMBOL_GPL c'est un flag qui a été ajouté pour permettre aux développeurs de définir plus facilement si leur code est sous GPL plus exception de linkage avec des drivers proprio ou GPL only. Ça a permis au contraire de simplifier les choses. C'est une amélioration technique plus que politique (avant c'était flou, plus après). J'aimerais bien qu'un expert noyau (patrickg ou autre) vienne nous en dire plus.
Pour finir, je connais des gens qui crackent leur Windows et leur Photoshop et qui n'ont aucun problème de conscience également, ça apporte quoi ce que tu viens de nous dire. Que tu t'en fous et que tu feras comme tu veux ? Ben bon cracking...
P.S. Est-ce que tu veux une petite musique en .mid avec le script qui crack le driver ATI et te l'installe ?
[^] # Re: Tu sais lire l'anglais ?
Posté par grid . Évalué à -1.
"Linux, aime-le ou quitte le", Joli discours. Bravo
>> C'est une amélioration technique plus que politique (avant c'était flou, plus après).
Tu refais l'histoire. Tu le dis toi mème, ce flag est utilisé pour restreindre les options de linkage des modules proprios sur les nouvelles interfaces. La raison n'est pas technique, mais bien politique.
>je connais des gens qui crackent leur Windows et leur Photoshop...
blablabla, Si tu ne sais pas faire la différence entre utiliser un driver proprio, et cracker un toshop. je ne peux rien pour toi. J'espère que tu n'utilises aucun blob proprio et que vrms retourne un magnifique zéro. Faut être cohérent.
> P.S. Est-ce que tu veux une petite musique en .mid avec le script qui crack le driver ATI et te l'installe ?
Fait péter, envoie moi la version midi de la Free Software song.
[^] # Re: Tu sais lire l'anglais ?
Posté par tiot (site web personnel) . Évalué à 2.
Ohh le joli sophisme.
Tu oublies que pour utiliser ton super driver proprio tu dois aller en l'encontre des droits d'auteur. Et lorsque tu crack toshop tu vas aussi à l'encontre du droit d'auteur.
Conclusion : il n'y a pas de différence, dans les deux cas tu ne respectes pas le droit d'auteur.
[^] # Re: Tu sais lire l'anglais ?
Posté par allcolor (site web personnel) . Évalué à 8.
Si c'est l'utilisateur lui-même pour son propre compte qui fait la manip, il n'y a rien d'illégal, ni qui va à l'encontre des droits d'auteur. Par contre si le résultat de la manip est distribué alors là c'est illégale (et ça l'est doublement car la distribution de fglrx c'est AMD et personnes d'autres sauf accord et c'est incompatible vis à vis de la GPL).
[^] # Re: Tu sais lire l'anglais ?
Posté par 2PetitsVerres . Évalué à 1.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Tu sais lire l'anglais ?
Posté par grid . Évalué à 3.
les licences proprio disent en général non, et il y en a qui le fond. protégé notamment par la loi française.
Donc, j'ai acheté le matos, je prends le droit de modifier le driver pour le faire fonctionner.
[^] # Re: Tu sais lire l'anglais ?
Posté par beagf (site web personnel) . Évalué à 3.
Par contre avec la conaissance acquise par retroingenieurie, tu peut réécrie un driver avec les modifs que tu souhaite.
[^] # Re: Tu sais lire l'anglais ?
Posté par tiot (site web personnel) . Évalué à 2.
Par contre je me pose la question par rapport au droit moral. Le développeur a dit qu'il ne voulait pas que son code soit lié à du propriétaire et tu le fais tout de même.
[^] # Re: Tu sais lire l'anglais ?
Posté par grid . Évalué à 2.
De la bouillie d'intégriste tout ça. Dans mon cas, l'auteur a touché de l'argent. J'ai acheté le GPU, je n'avais pas réussi à trouver le torrent de la carte graphique.
[^] # Re: Tu sais lire l'anglais ?
Posté par Sébastien Le Ray . Évalué à -1.
>> Si c'est l'utilisateur lui-même pour son propre compte qui fait la manip, il n'y a rien d'illégal, ni qui va à l'encontre des droits d'auteur.
Ah bon ? Dans ce cas (pour reprendre l'exemple précité) si je cracke la démo de photoshop pour virer la limite de durée je fais rien d'illégal ?
>> Dans mon cas, l'auteur a touché de l'argent. J'ai acheté le GPU, je n'avais pas réussi à trouver le torrent de la carte graphique.
Le matériel t'appartient effectivement, libre à toi d'aller y souder une guirlande électrique. Par contre en matière de logiciel tu as uniquement un droit d'utilisation, ce n'est pas parce que tu peux modifier le code que tu en as le droit ou que c'est légal.
[^] # Re: Tu sais lire l'anglais ?
Posté par Guillaume Rossignol . Évalué à 9.
Ah bon ? Dans ce cas (pour reprendre l'exemple précité) si je cracke la démo de photoshop pour virer la limite de durée je fais rien d'illégal ?
Il parle de la GPL lorsqu'il dit qu'on a le droit de faire ce qu'on veut avec du GPL tant qu'on ne le redistribue pas... et il se trouve que c'est vrai :
- Droit d'utiliser le logiciel quelque soit l'usage
- Droit d'etudier le logiciel
- Droit de le modifier
- Droit de le re-diffuser (ou de diffuser ses modifications) à la condition de garder la licence
Donc j'ai parfaitement le droit de faire sauter tout ce que je veux, comme je veux, sur mon noyau tant que je ne le redistribue pas.
La licence de photoshop ne t'autorise pas à modifier ou étudier le fonctionnement du logiciel.
[^] # Re: Tu sais lire l'anglais ?
Posté par Prosper . Évalué à -1.
Sauf que la il ne modifie pas le noyal mais le source du glue fglrx qui lui n est absolument pas GPL .
[^] # Re: Tu sais lire l'anglais ?
Posté par allcolor (site web personnel) . Évalué à 5.
[^] # Re: Tu sais lire l'anglais ?
Posté par Sébastien B. . Évalué à 8.
[^] # Re: Tu sais lire l'anglais ?
Posté par Guillaume Rossignol . Évalué à 2.
[^] # Re: Tu sais lire l'anglais ?
Posté par B16F4RV4RD1N . Évalué à 4.
Qui fait tourner un driver proprio sans respecter l'esprit de la GPL en viendra forcément à cracker un toshop et à tuer des bébés pingouins.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Tu sais lire l'anglais ?
Posté par Guillaume Knispel . Évalué à 2.
[^] # Re: Tu sais lire l'anglais ?
Posté par Cyril Brouillard (site web personnel) . Évalué à 3.
je suis parti -->[ ]
# Interet ?
Posté par Pascal Terjan (site web personnel) . Évalué à 9.
[^] # Re: Interet ?
Posté par Dup (site web personnel) . Évalué à -2.
Après il en a surement pas besoin.
[^] # Re: Interet ?
Posté par B16F4RV4RD1N . Évalué à 3.
Et pourquoi un pilote 3D "pas libre" ? Ben pour pouvoir jouer à des jeux 3D.
Bref, avoir un ordinateur configuré pour des utilisations "basiques", cela ne me semble pas trop demander, mais visiblement c'est trop indécent.
On dirait que la GPL est à l'informatique ce que Amélie Poulain est au bonheur : Elle sait mieux que vous ce qui est bon pour vous.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Interet ?
Posté par Troy McClure (site web personnel) . Évalué à 3.
[^] # Re: Interet ?
Posté par bubar🦥 (site web personnel) . Évalué à -2.
après il va se poser la question "mais à quoi ça peux me servir à moi ?" et peut être qu' il fera du traitement de signal audionumérique avec ? et peut être qu' après il se tournera vers des hyperviseurs assurant la preeempt sur les irq aussi ?
/me retourne au bar, désolé
[^] # Re: Interet ?
Posté par grid . Évalué à 1.
On se connait pour que tu saches que je n'ai pas besoin du patch RT ?
Ensuite, je poste un lien vers un forum ubuntu, donc, je suis utilisateur ubuntu. Là encore tu as une boule de cristal ?
[^] # Re: Interet ?
Posté par motörhead . Évalué à 3.
On se connait pour que tu saches que je n'ai pas besoin du patch RT ?
Ben en l'occurence, tu utilises le patch RT mais ton temps réel est en fait "cassé" par la présence d'un driver video accéléré, et donc ton noyau n'est pas temps réel.
On constate aussi que tu n'as remarqué aucun problème lié à cette utilisation conjointe, en tout cas tu ne t'en plains pas dans ton journal.
En conséquence, si ton noyau n'est pas temps réel et que tu n'as remarqué aucun problème c'est que tu n'en avais pas besoin, du temps réel.
[^] # Re: Interet ?
Posté par Troy McClure (site web personnel) . Évalué à 6.
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 ?
[^] # Re: Interet ?
Posté par motörhead . Évalué à 6.
Le noyau temps réel de linux (on parle ici de temps réel dur), avec les bonnes conditions (matos pas complètement rachitique, pas de drivers qui font n'importe quoi) te donne l'assurance que ça fonctionnera 100% du temps (et pas 99.99%), à savoir que ta requête audio sera traitée dans les XX microsecondes à tous les coups.
Windows et MacOS ne peuvent pas donner cette garantie.
[^] # Re: Interet ?
Posté par thedude . Évalué à 3.
On voit souvent des grands nom de la musique electronique faire des lives avec leurs laptop sur scene.
J'ai pas de noms, mais c'est tres rare de voir un liveux uniquement avec des machines, ils ont generalement un laptop sur scene.
Je sais pas, disons garnier par ex, en session live devant 50 000 personnes dans une grosse salle.
Question, peut etre naive, donc.
Comment ils font ces gens la?
Parce que je vois pas Mossieur Laurent Garnier hocher la tete en disant "mmmaaa!! tant pis." devant un skip en plein concert.
[^] # Re: Interet ?
Posté par totof2000 . Évalué à 5.
[^] # Re: Interet ?
Posté par thedude . Évalué à 2.
J'ai bien entendu parler de midi, mais c'est toujours pareil, si le noyau skip l'interrupt real time, tu l'as dans l'os, que t'aies 20 000 euros de matos au cul de la prise midi ou un clavier a 10 francs.
[^] # Re: Interet ?
Posté par Moogle . Évalué à 2.
Autre concert plus récemment il y a un mois ou deux, toujours Garnier, avec pareil un petit "bug" en plein concert. Je ne sais pas si c'était une erreur humaine ou machine, toujours est-il qu'il s'est produit et ça n'a pas fait scandale pour autant.
[^] # Re: Interet ?
Posté par thedude . Évalué à 3.
Bon, pour la coupure de courant, on peut pas trop imputer ca au cote real time du kernel quand meme :)
Je ne sais pas si c'était une erreur humaine ou machine, toujours est-il qu'il s'est produit et ça n'a pas fait scandale pour autant.
Tant qu'il ya pas d'emeutes tout va bien... :)
Plus serieusement, le fond de mon commentaire c'est que si des grands noms de l'electro tournent avec ce genre de config (et ils tournent avec ce genre de config, clairement), la config n'est pas si pourri que ca.
On est donc bel et bien en droit de se demander pourquoi du rt dur est necessaire pour l'un alors que du preemptif tout ballot suffit pour les 2 autres (La reponse "chez les autres ca marche pas en fait" n'etant visiblement pas valable puisque ya qu'a ouvrir ses oreilles pour se rendre compte que ca marche, en fait).
[^] # Re: Interet ?
Posté par grid . Évalué à 3.
Toutes les docs en MAO demande en prérequis un noyau RT.
genre http://www.linuxmao.org/tikiwiki/tiki-index.php?page=compile(...)
[^] # Re: Interet ?
Posté par spart . Évalué à 7.
> necessiter un noyau "spécial" pour faire de l'audio
mais là tu es complètement à côté de la plaque et tu renverses le problème...
c'est juste le seul OS 'grand public' qui offre la possibilité d'un mode temps réel.
Il ne s'agit pas de "faire de l'audio" en général, mais bien de faire de l'audio temps réel, ce qui n'a rien à voir. Tous les musiciens qui ont essayé ça sur un OS 'normal' te diront qu'il faut accepter
1) une latence perceptible à l'oreille et qui donne de la mollesse au clavier
2) des sautes de son occasionnelles
3) un manque de fiabilité qui s'aggrave avec le temps d'exécution
des logiciels
Le noyau temps réel est pour ceux qui ne veulent pas tolérer ces aléas.
Je sais, pour utiliser régulièrement les deux types de noyaux avec un synthétiseur d'orgue à tuyau maison (synthés + pédalier hoffrichter + midisport 4x4 + linuxsampler + jack + genpo) que la fiabilité des deux n'a absolument rien à voir.
Un noyau RT, c'est une expérience incroyable, un niveau de fiabilité que tu ne rencontres que dans l'électronique dédiée : tu peux laisser ton synthé tourner 3 semaines, plaquer brutalement un accord de dix notes, et obtenir un son parfait en moins de 7 milisecondes.
Tu peux jouer et oublier totalement le matériel : c'est un véritable instrument.
Tu m'étonnes que les musiciens se jettent dessus...
AUCUN autre OS généraliste ne permet ça, et les rares systèmes propriétaires qui le permettraient n'ont absolument pas le choix de logiciels dont on dispose sous linux - c'est un écosystème très riche.
[^] # Re: Interet ?
Posté par spart . Évalué à 1.
linuxsampler, c'est pour le clavecin =<:-]
[^] # Re: Interet ?
Posté par Troy McClure (site web personnel) . Évalué à 3.
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/ )
[^] # Re: Interet ?
Posté par spart . Évalué à 4.
> (3ms par ex).
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 !
> 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.
oui, c'est pour ça que pratiquement toutes les applis temps réel préfèrent utiliser le serveur Jack, dont l'API est conçue pour ça et rend ce genre de débordements difficiles.
>Y'a quand même des gens qui utilisents des laptops sur scene sous windows
> ou macos et qui n'ont pas de problemes.
ils ne l'utilisent certainement pas pour de la synthèse temps réel... ça ne marche pas !
Pour lancer des événements midi peut-être ? si on a pas de gros besoin de synchronisation et du bon matos, c'est sûrement tout à fait jouable.
Déjà pour faire de la lecture de flux multipiste, c'est très très limite... j'ai bossé quelques temps à la régie d'un théâtre, et je peux te dire que lancer un événement son sur un système windows te donnes toujours des sueurs froides...
le résultat était complètement imprévisible, même en supprimant tous les serveurs en tâche de fond imaginables et en réduisant les interactions à l'extrême.
>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 ?
difficile de répondre, c'est sans doute un tout, mais peu importe...
ce qu'on voit, c'est que le système n'est pas assez préemptif pour ce genre d'utilisation - on peut en venir à assurer son bon fonctionnement pour quelque temps, mais au-delà l'entropie d'exécution rend toute certitude caduque, là où un système temps réel offre une marge beaucoup plus grande.
> 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
non, c'est vraiment très riche si tu regarde du côté du temps réel, avec une constellation de petites ou moyennes applis qui fonctionnent en parfaite symbiose additive autour d'un serveur Jack - te donnant des possibilités de synthèse délirantes.
(il y a déjà quelques pistes là: http://jackaudio.org/applications même si c'est moyennement à jour)
La variété est considérable, depuis les petits trucs atypiques mais super efficaces à la ZynAddSubFX, jusqu'aux langages de programmation sonore complets comme CSound, en passant par les effets LADSPA...
Et puis bien sûr, les excellents lecteurs de samples comme fluidsynth et linuxsampler, qui offrent une compatibilité excellente avec l'énorme bibliothèque des échantillons Gigastudio et autres banques SF2, mais avec la fiabilité du temps réel...
[^] # Re: Interet ?
Posté par Troy McClure (site web personnel) . Évalué à 1.
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 ?
[^] # Re: Interet ?
Posté par spart . Évalué à 2.
Si tu mesures à l'oscillo les temps de réaction d'un système non-RT pour un appel système, tu t'apercevras qu'en moyenne le temps de réponse est dans les 15 à 20 ms, quelque soit l'OS (contre +/- 50 micro secondes en RT - un facteur presque mille !).
Tu vois bien que dans ces conditions, il ne sert à rien de réclamer une précision de 3ms à un système qui ne peut de toute façon pas te les fournir.
Peut-être que tu auras tes 3 ms quelques secondes, au petit bonheur, jusqu'à ce que ton appli soit préemptée par une tâche de fond ou un accès disque ou que sais-je... et là tu auras ce qu'on appelle des Xruns dans le jargon de Jackd : des décrochages plus ou moins long du buffer.
Jack t'en informe et les compte, ce qui te permet de régler les valeurs de buffer jusqu'à ce que ça n'arrive plus. J'imagine que les applis Windows ne te le disent pas, c'est tout...
En tout cas, la qualité de l'audio produite sera très inégale. 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.
> 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 ?
Mais c'est complètement notoire ! fais quelques recherches sur le sujet et tu verras.
Quant aux éditeurs de synthés, ils ne dépendent que du niveau d'exigence de leur public. La qualité non-RT peut sans doute suffire pour un usage non-pro ou occasionnel... il faut vraiment pas avoir beaucoup d'oreille en tout cas ;-/
Pour les pros, eh ben, bien sûr qu'ils se précipitent sous linux... leur seul problème est de s'adapter au système, ce qui n'est pas forcément évident - c'est pour ça qu'on voit apparaître des produits du genre du "Receptor" dont tu me parlais. Va donc regarder la FAQ du lien que tu me donnais dans ton autre commentaire, c'est édifiant :
http://www.museresearch.com/receptor.php?r=faq
ils font tourner un système de plugin Windows sur un Linux RT pour que leurs utilisateurs gardent le confort de leurs habitudes et de leur réglages Windows, mais avec la précision et la qualité sonore qu'apporte le RT.
C'est quand même un comble :-)
[^] # Re: Interet ?
Posté par Troy McClure (site web personnel) . Évalué à 2.
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.
[^] # Re: Interet ?
Posté par spart . Évalué à 1.
Moi quand j'observe la console de Jack, je n'entends pas d'erreur évidente pour tous les micros-xruns. Ça provoque juste une baisse globale de qualité quand ils sont nombreux.
Si tu n'as pas ce genre d'information, et que tu te repères aux "craquements bein audibles", en effet on est pas tout à fait dans la même optique ^^;;
[^] # Re: Interet ?
Posté par Troy McClure (site web personnel) . Évalué à 4.
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 ?
[^] # Re: Interet ?
Posté par Guillaume Knispel . Évalué à 2.
Dans le cas audio il y a peut-être des spécificités qui induisent cette latence de 15 à 20 ms, le cas le plus trivial que je puisse imaginer étant que les tampons servant d'interface kernel <-> user (ou hard <-> user si ya des techniques de sioux genre mmaping) ont tout simplement une taille de 20 ms typiquement pour ne pas prendre le risque d'interrompre le flux audio en cas de latence irrégulière (jitter) de la latence de traitement des IT.
Néanmoins, si tous les drivers que tu utilises sur un système Linux moderne (non RT) sont de qualité décente (et pour ma part j'aurais assez tendance à considérer qu'un driver qui coupe les IT ou fait tourner une hardirq pendant plusieurs ms est de la merde en boite), tu auras en pratique une latence + jitter largement inférieure à 1 ms et a mon avis des tampons de 1 à 2 ms seraient théoriquement envisageable. Pour du 50 us, je suis effectivement d'avis qu'un système RT est indispensable.
[^] # Re: Interet ?
Posté par grid . Évalué à 2.
2) je ne cherche pas du temps réel dur, j'utilise jack pour de l'enregistrement musicaux, et le système sonore de Linux est tellement pourri que pour avoir des perf potables, il faut le noyaux RT, et pour ne devrais-je pas utiliser la 3D en RT ?
[^] # Re: Interet ?
Posté par motörhead . Évalué à 4.
2) je ne cherche pas du temps réel dur, j'utilise jack pour de l'enregistrement musicaux, et le système sonore de Linux est tellement pourri que pour avoir des perf potables, il faut le noyaux RT, et pour ne devrais-je pas utiliser la 3D en RT ?
Par exemple, si un driver fait un gros DMA qui bloque le bus pendant quelques millisecondes, ton CPU sera bloqué pour ses acces mémoire et tu peux alors rater une ou des échéances RT. Pour faire du RT il faut que tous les drivers soient adaptés (i.e. qu'ils promettent de pas faire de gros DMA d'un coup par exemple). A ma connaissance peu le sont, et les pires sont les drivers graphiques pour ça.
Ah oui, les drivers graphiques libres ne sont pas RT-safe non plus.
[^] # Re: Interet ?
Posté par motörhead . Évalué à 0.
Ah oui, j'ajoute que si on tient vraiment à utiliser X sur un système RT, on peut utiliser le driver vesa, qui s'il ne fait pas des étincelles permet d'éviter ces problèmes puisqu'il ne fait pas d'accélération non plus.
[^] # Re: Interet ?
Posté par vincent_k (site web personnel) . Évalué à 2.
[^] # À propos de PulseAudio...
Posté par nicoastro . Évalué à 1.
J’en tire la conclusion que ce n’est certainement pas Pulse qui est à remettre en cause.
[^] # Re: À propos de PulseAudio...
Posté par grid . Évalué à 4.
Une intégration trop rapide dans les distribs par rapport à la maturité du projet.
[^] # Re: À propos de PulseAudio...
Posté par Anonyme . Évalué à 2.
Entre autres : on ne peut pas l'utiliser avec une sortie optique, parce qu'il gère pas le passthrougt.
[^] # Re: À propos de PulseAudio...
Posté par JoeBar . Évalué à 1.
Ben je le fais pourtant tous les jours... Tant que ça reste du stéréo c'est niquel. Après dès qu'il faut lire un film en AC3, là mplayer s'adresse directement à Alsa. Mais dans l'ensemble je suis content de pulse audio, quand tu as deux cartes son c'est quand même le pied !
Par contre pour ce qui est de l'enregistrement impossible de le faire marcher... j'ai pas beaucoup cherché mais les résultats obtenus sont très bizarres, de rien du tout à un son très haché inaudible qui n'a rien à voir avec l'original.
[^] # Re: Interet ?
Posté par ChickenKiller . Évalué à 2.
(ceci est une vrai question)
[^] # Re: Interet ?
Posté par Guillaume Knispel . Évalué à 1.
Et que de toute façon sauf si le RT est implémenté par NMI, tu cours le risque que le driver proprio coupe de lui même les IT et qu'il te nique donc de toute manière l'aspect RT...
[^] # Re: Interet ?
Posté par grid . Évalué à 3.
Et je ne connais pas grand chose de pire que d'avoir une résolution pas adapté sur un écran TFT.
[^] # Re: Interet ?
Posté par ʭ ☯ . Évalué à 2.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Interet ?
Posté par Guillaume Knispel . Évalué à 2.
Ce que je veux dire c'est qu'à partir du moment où tu utilises un driver proprio sous Linux, quelqu'en soit la raison, tu prends le risque que certaines fonctionnalités de Linux fonctionnent moins bien, surtout celles soumises à compilation conditionnelle.
# GPL, toujours la même erreur
Posté par IsNotGood . Évalué à 7.
Mais une incompatibilité c'est dans les deux sens. Je ne peux pas mettre du non compatible GPL dans du GPL, je ne peux pas mettre du GPL dans du non compatible GPL.
> Pour autoriser certains développeurs à interdire l'accès à leur code aux drivers propriétaires.
C'est l'inverse. Qu'importe.
Pour le noyau qui est sous GPL, il y a deux écoles : Linus et RMS (ils ne sont pas uniquement en opposition). Certains pensent qu'un modules noyau est seulement une utilisation du noyau et d'autre qu'un module est un travail dérivé du noyau. Pour satisfaire presque tout le monde il y a ce que tu qualifies d'horreur A TORT !
[^] # Re: GPL, toujours la même erreur
Posté par pasBill pasGates . Évalué à 6.
Mais une incompatibilité c'est dans les deux sens. Je ne peux pas mettre du non compatible GPL dans du GPL, je ne peux pas mettre du GPL dans du non compatible GPL.
Euh non, c'est dans un sens seulement.
MS ne t'empeche pas de linker ton code GPL avec ses librairies par exemple, ils n'ont aucune restriction vis-a-vis de la licence du code qui link, mais la GPL elle peut l'empecher(si la lib est non-systeme et non-GPL).
Si tu le faisais, tu ne violerais pas la licence de MS, mais tu violerais la GPL, c'est donc bien la GPL qui te l'interdit et pas l'inverse.
[^] # Re: GPL, toujours la même erreur
Posté par benoar . Évalué à 5.
La licence MS dit "rien à battre de ta liberté, et de toutes façons t'as pas les sources". Et en plus, tu as une première restriction, avant d'essayer d'y linker quoi que ce soit : il faut l'avoir acheté, et accepté les conditions d'utilisation de MS.
Parler de "restriction" dans ce sens là est plus juste ; je trouve que le mot est détourné quand il est appliqué à la GPL.
[^] # Re: GPL, toujours la même erreur
Posté par pasBill pasGates . Évalué à 2.
Peu importe le pourquoi, au finale c'est la GPL qui empeche la connection, pas l'autre licence.
La licence MS dit "rien à battre de ta liberté, et de toutes façons t'as pas les sources".
Ouaip, et elle te dit aussi "t'as la liberte d'utiliser la licence que tu veux pour ton code", liberte que la GPL te donne pas.
Et en plus, tu as une première restriction, avant d'essayer d'y linker quoi que ce soit : il faut l'avoir acheté, et accepté les conditions d'utilisation de MS.
L'avoir achete ?
http://www.microsoft.com/downloads/details.aspx?FamilyID=A33(...)
Download gratuit, tu peux utiliser cette librairie depuis des langages de script(VBScript, Perl, ...).
Pas besoin de payer la librairie, pas besoin de payer pour un compilo, suffit d'avoir l'OS.
[^] # Re: GPL, toujours la même erreur
Posté par benoar . Évalué à 2.
Et pourquoi ne pas le voir dans le sens "c'est l'autre licence qui m'en empêche, car elle ne me permet pas de redistribuer son code source (que je n'ai de toutes façons pas) en respectant mes libertés" ?
Pas besoin de payer la librairie, pas besoin de payer pour un compilo, suffit d'avoir l'OS.
Tu vois pas la contradiction dans cette phrase ?
[^] # Re: GPL, toujours la même erreur
Posté par pasBill pasGates . Évalué à 0.
Parce que :
a) Ces "libertes" sont relatives, moi je trouves pas la GPL plus libre qu'une autre d'un point de vue de developpeur, ce qu'elle donne elle le prend de l'autre cote.
b) Une lib GPL te force a donner ton propre code pour l'utiliser en cas de redistribution, une lib non-GPL ne le fait pas, t'as le choix, resultat, c'est bien la GPL qui met la restriction et personne d'autre. C'est peut-etre cool pour l'utilisateur qui sait, mais pour le developpeur c'est clairement une restriction.
Tu vois pas la contradiction dans cette phrase ?
Non aucune, vu que si tu fais du pur GPL sur Windows faut aussi payer l'OS, et si tu prends une lib avec ce type de licence sur Linux t'as pas besoin de payer l'OS, bref le cout de l'OS est totalement independant de la licence des softs par dessus.
[^] # Re: GPL, toujours la même erreur
Posté par thedude . Évalué à 4.
Parce que quand tu distribue un binaire, lie a du code GPL, la dite GPL dudit code lie t'oblige a distribuer tes sources se basant sur ce code. Ou a ne pas distribuer le binaire.
En clair: le choix d'une lib GPL contraint la licence de ton code a etre GPL like.
C'est pas nouveau et c'est meme le but de cette licence.
Quand tu distribue un binaire, lie a code MS, la licence de MS ne t'oblige a rien.
Tu peux distribuer les sources. Ou pas. C'est toi qui voit.
Mais tu n'es pas OBLIGE de distribuer tes sources.
C'est pas nouveau et c'est meme le but de cette licence, MS ne veut pas mettre de batons dans les roues aux gens qui developpent sur sa plateforme et ne leur impose pas de contrainte sur leur choix de licence.
C'est aussi la raison pour laquelle la libc est distribuee en GPL avec exception ou LGPL (desole, j'ai un trou): parce qu'on veut que les gens utilisent le systeme, on les laisse donc utiliser le binaire tout leur saoul, tant qu'il ne le modifient pas.
Quand a la licence des sources de la lib, et ben c'est pas la meme et ca tombe bien, parce que c'est pas le meme produit. La question de la redistribution de ces sources est donc separee du link vers la lib binaire.
En clair, le choix de certaines lib MS ne contraint pas du tout ton choix de licence (certaines, parce que je suis pas sur que 100% des libs MS soient aussi permissives, mais pb pg est surement mieux place que moi pour confirmer/infirmer).
Apres, tu peux vouloir choisir une licence qui sera incompatible, mais c'est cette licence et ton choix qui cree l'incompatibilite.
C'est donc bel et bien la GPL qui cree l'incompatibilite, et cet effet est voulu en plus, depuis le debut.
Ce que les gens qui clament que l'incompatibilite est reciproque ont visiblement du mal a assumer.
[^] # Re: GPL, toujours la même erreur
Posté par Guillaume Knispel . Évalué à 3.
De toute manière les deux cas sont difficilement complètement comparables. Dans le cas MS tu perds la possibilité de redistribuer le code source de la bibliothèque MS, que de toute façon tu n'as typiquement pas :p
[^] # Re: GPL, toujours la même erreur
Posté par thedude . Évalué à 2.
Certes, mais c'etait un exemple pour montrer que l'incompatibilite vient bel et bien de la GPL et de personne d'autre.
[^] # Re: GPL, toujours la même erreur
Posté par BAud (site web personnel) . Évalué à 5.
ah, les bibliothèques de Microsoft ont une licence compatible avec la GPL ? Je peux donc aussi distribuer le code source intégral de mon binaire linké en statique avec ces bibliothèques pour respecter la GPL ? Je crains bien que non, dans le cas général, la licence retenue par Microsoft ne me permet que d'avoir des liens dynamiques (quand j'ai le droit de distribuer ces même bibliothèques d'ailleurs...).
Mauvais choix de licence chez Microsoft, changer de licence... ça marche bien dans les deux sens, l'incompatibilité ne présageant pas que l'un plus que l'autre est incompatible... chacun ses choix et visiblement celui de Microsoft n'est pas celui du libre (ni du propriétaire - au bénéfice d'autres que lui - bien souvent non plus...). Tu peux remballer tes arguments non ?
[^] # Re: GPL, toujours la même erreur
Posté par pasBill pasGates . Évalué à 1.
Tu vois, tu le dis toi-meme : "pour respecter la GPL", la licence des librairies MS n'est pas le probleme, le probleme c'est la GPL.
Mauvais choix de licence chez Microsoft, changer de licence... ça marche bien dans les deux sens, l'incompatibilité ne présageant pas que l'un plus que l'autre est incompatible... chacun ses choix et visiblement celui de Microsoft n'est pas celui du libre (ni du propriétaire - au bénéfice d'autres que lui - bien souvent non plus...). Tu peux remballer tes arguments non ?
Voyons, un dit "utilisez la licence que vous voulez avec votre code, on se fiche de ce que vous faites avec votre code a vous", l'autre dit "si c'est pas du GPL aussi, c'est non".
Il y a comme une legere difference.
[^] # Re: GPL, toujours la même erreur
Posté par geb . Évalué à 3.
Il est toutefois bien connu que si les bsdistes rechignent à utiliser du code sous GPL,
c'est bien parce que leur licence maison est trop restrictive.
[^] # Re: GPL, toujours la même erreur
Posté par Anthony Jaguenaud . Évalué à 4.
J'aimerai poser des questions simples.
Je fais une bibliothèque quelle licence choisir ?
GPL :
Si quelqu'un lie un programme à ma bibliothèque, son programme doit-il être GPL ?
Si quelqu'un modifie ma bibliothèque, la nouvelle bibliothèque doit être en GPL.
BSD:
- Dans les deux cas il fait ce qu'il veux de son programme.
LGPL:
- Le programme peut avoir la licence qu'il veut.
- Une modification de la bibliothèque implique une distribution du code en même temps que le binaire ainsi que de garder l'historique : auteur, licence ?
Autre ?
[^] # Re: GPL, toujours la même erreur
Posté par allcolor (site web personnel) . Évalué à 2.
GPL :
Si quelqu'un lie un programme à ma bibliothèque, son programme doit-il être GPL ?
Si quelqu'un modifie ma bibliothèque, la nouvelle bibliothèque doit être en GPL.
Oui et Oui
BSD:
- Dans les deux cas il fait ce qu'il veux de son programme.
Oui (mais il fait aussi ce qu'il veut de ta lib)
LGPL:- Le programme peut avoir la licence qu'il veut.
- Une modification de la bibliothèque implique une distribution du code en même temps que le binaire ainsi que de garder l'historique : auteur, licence ?
Oui et non (implique seulement de pouvoir fournir le code source et les modifs)
[^] # Re: GPL, toujours la même erreur
Posté par 2PetitsVerres . Évalué à 2.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: GPL, toujours la même erreur
Posté par allcolor (site web personnel) . Évalué à 2.
Comme par exemple pour:
http://www.fltk.org/COPYING.php et http://teem.sourceforge.net/lgpl.html (trouvé avec google)
[^] # Re: GPL, toujours la même erreur
Posté par Anthony Jaguenaud . Évalué à 2.
LGPL:Oui et non (implique seulement de pouvoir fournir le code source et les modifs)- Le programme peut avoir la licence qu'il veut.
- Une modification de la bibliothèque implique une distribution du code en même temps que le binaire ainsi que de garder l'historique : auteur, licence ?
Heu, j'ai pas bien compris, où tu as mal compris ma question en tous cas, je demande un éclaircissement pour la modification de la bibliothèque.
Si je comprends bien, l'auteur qui a modifié la bibliothèque, doit redistribuer aux personnes à qui il distribue la nouvelle version de la bibliothèque mes sources, et ces patch.
Je reste dans le cas du lien dynamique.
[^] # Re: GPL, toujours la même erreur
Posté par allcolor (site web personnel) . Évalué à 2.
qui il distribue la nouvelle version de la bibliothèque mes sources, et ces patch.Oui mais seulement si ceux-ci demande le source, il n'y a pas d'obligation de distribuer le source avec le binaire, seulement de le fournir si une personne a qui tu as distribué le soft le demande.
Donc ce que je disais c'est qu'ils ont l'obligation de pouvoir le faire si on le demande, pas l'obligation de livrer les sources en même temps que le binaire.
# Tati 3D 100% polyuree de chat
Posté par Grumbl . Évalué à 4.
[^] # Re: Tati 3D 100% polyuree de chat
Posté par Sébastien B. . Évalué à 0.
Punaise, ça doit être la 5ème fois que je passe devant ton message et je viens de comprendre !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.