gouttegd a écrit 1805 commentaires

Tout programmeur qui a pratiqué l'orienté objet suffisamment a déjà rencontré ce cas où il ne sait pas où placer une classe dans l'arbre d'héritage parce qu'elle irait bien à deux endroits différents.

N’est-ce pas là le cas typique où il faut appliquer le principe de « composition plutôt qu’héritage » ?

D’après le trésor de la langue française, la forme correcte serait « s’en est ensuivi », mais le TLF note que cet usage est tombé en désuétude au profit de « s’en est suivi », malgré « l’incorrection certaine » de cette forme :

Néanmoins, on ne dit plus il s’en est ensuivi, mais plutôt, malgré l'incorrection certaine, il s'en est suivi.

Et donc tu te retrouves rapidement à tweaker Jack pour l’adapter à une utilisation pour laquelle il n’est pas conçu…

Je le répète : tu peux le faire sur ta machine si tu le tiens vraiment, mais aucune distribution généraliste (a fortiori aucune distribution « grand public » à la Ubuntu) ne fera ça par défaut, pour plusieurs raisons :

– personne à part toi ne semble penser que ça pourrait être une bonne idée ;
– en particulier, aucun développeur upstream (que ce soit du côté de Jack, de PulseAudio, ou de tous les programmes cherchant à jouer du son) n’accorde du crédit à cette idée — donc si une distribution s’avisait de faire ça, ses mainteneurs ne pourraient vraisemblablement pas compter sur le soutien des développeurs ;
– une distribution qui (juste pour pouvoir utiliser Jack comme serveur de son par défaut) limiterait les choix de l’utilisateur aux quelques programmes connus pour supporter Jack ? Franchement, ça intéresserait qui ? Ceux qui ne veulent catégoriquement pas de PulseAudio ? S’ils ont de bonnes raisons de ne pas vouloir PulseAudio, ils s’y connaissent déjà probablement assez pour savoir comment s’en passer.

Rapidement, quelques éléments de réponse.

a) D’abord, on peut utiliser Jack comme serveur de son général par défaut, mais… si quasiment tous les programmes dédiés à la production musicale supportent Jack, c’est loin d’être le cas de tous les programmes pouvant avoir besoin d’émetre du son ; et à ma connaissance, il n’y a pas de couche de compatibilité permettant aux programmes ALSA d’utiliser Jack de façon transparente, comme c’est le cas avec PulseAudio.

b) PulseAudio et Jack n’ont pas du tout les mêmes objectifs, ce sur quoi s’accordent leurs développeurs respectifs : voici ce qu’en dit Lennart Poettering, et ce qu’en dit Paul Davis (beaucoup plus succintement, dans le deuxième paragraphe). Les deux serveurs ne sont donc pas interchangeables.

Par exemple, là où PulseAudio s’accommode de sources utilisant des formats différents (fréquence et taille des échantillons), Jack impose un format unique à tous ses clients, ce qui n’est pas forcément judicieux pour un serveur de son qui serait destiné à être utilisé par toutes les applications du bureau (alors que c’est parfaitement acceptable pour les quelques applications dédiées à l’audio pro).

Du coup, le principe du « qui peut le plus peut le moins » n’est pas applicable ici, ou du moins pas dans le sens que tu souhaites : en fait c’est PulseAudio qui en fait « plus » que Jack (d’où sa plus grande complexité).

c) Enfin, et sur un plan non-technique : PulseAudio est en bonne passe de devenir le serveur de son standard sous GNU/Linux, ce à quoi ses prédécesseurs comme arts ou esd ont toujours échoué. Maintenant qu’on est sur le point d’avoir une solution unifiée (qui a dit « enfin » ?), est-ce vraiment le moment de changer de direction et de partir sur une autre base ? Si PulseAudio n’est pas parfait, corriger ses défauts me semble une bien meilleure option que de le remplacer complètement par autre chose. Et je dis ça en n’étant pas un grand fan de PulseAudio, que je n’utilise personnellement pas.

d) Enfin (pour de bon cette fois), rien ne dit que si Jack connaissait la même utilisation intensive que PulseAudio, il ne serait pas exposé aux mêmes critiques (usine à gaz, couche supplémentaire inutile-parce-qu’après-tout-avec-ALSA-ça-marche-déjà-très-bien™, personne n’a besoin de pouvoir envoyer du son à travers le réseau, c’est nul mon programme préféré ne peut pas accéder à la carte son parce que Jack la monopolise, etc.). Jack ne fait pas l’objet de critiques (ou alors elles sont vraiment très discrètes) parce que tout ceux qui s’en servent en avaient besoin et l’ont choisi ; impose-le à tous les utilisateurs de distribution généraliste comme s’est imposé PulseAudio, je ne suis pas sûr qu’il serait mieux accueilli.

Mes deux cents.

Je ne comprends pas. Comment Pulseaudio altèrererait le son? Il n'est pas sensé faire de traitement du signal (au sens propre: FFT, etc…), pourtant?

Si, PulseAudio ré-échantillonne tous les signaux qui lui parviennent à la même fréquence d’échantillonnage avant d’envoyer le résultat à la carte son.

Ce serait une des causes de sa consommation de CPU jugée parfois excessive, en fonction de l’algorithme de ré-échantillonnage utilisé.

Tu le fais exprès ou quoi?

Je te retourne la question.

Tu dis que les applications doivent modifier leur comportement pour PulseAudio

Non, je dis qu’elles devraient. Une couche de compatibilité, c’est très bien, mais c’est au mieux un pis-aller pour les applications trop vieilles (qui ne sont plus maintenues) et une solution temporaire pour les autres en attendant que leurs développeurs implémentent le support direct de PulseAudio. Ça ne devrait pas être considéré comme une solution définitive. Ce n’est certainement pas une solution idéale en tout cas.

Si on devait se contenter d’utiliser des couches de compatibilité, aujourd’hui on se retrouverait avec des applications audio toujours conçues pour fonctionner avec OSS et qui ne fonctionneraient sous GNU/Linux que grâce à la couche de compatibiltié OSS que fournit ALSA…

Tu enchaines en disant que PulseAudio ne fonctionne pas parce que la couche de compatibilité n’est pas installé, je te réponds que c’est faux. […] Si ça merde, ça vient d’un bug du logiciel ou d’un problème dans l’intégration

OK, je te l’accorde : je ne fais pas la différence entre une couche de compatibilité non-installée et une couche de compatibilité qui ne fonctionne pas à cause d’un bug ou un problème d’intégration quelconque. Je ne suis pas sûr que la différence soit très importante pour l’utilisateur, cela dit.

Faudrait pas prendre ceux qui les équipes derrières les distributions GNU/Linux pour des quiches non plus.

J’ai déjà vu quelques erreurs d’empaquetage assez pendables, toute distribution confondue. Je ne prends pas les développeurs pour des quiches, mais personne n’est à l’abri d’une erreur.

Et bien sûr, ça a toujours été le cas, n’est-ce pas ? Personne n’a jamais eu à se plaindre d’une mauvaise intégration de PulseAudio dans les distributions grand public, ça se saurait. Ce type qui se plaint du travail des empaqueteurs PA chez Ubuntu est sûrement un vil Poettering-hatter qui aime à répandre du FUD sur PulseAudio, n’est-ce pas ?

OK, ces problèmes sont maintenant réglés, les empaqueteurs ont appris à intégrer PA correctement (ce qui n’est pas une mince affaire, d’après le même type — « Adopting PA in a distribution is a fair amount of work, given that it interfaces with so many things at so many different places » — mon dieu, pourquoi tant de FUD ?). Tant mieux. Mais j’essaie d’expliquer comment PulseAudio a, par le passé, gagné sa réputation d’empêcheur de jouer du son en rond, réputation, on le voit, dont il a encore du mal à se débarrasser aujourd’hui.

sudo pacman -S pulseaudio{,-alsa}

Tu dois installer pulseaudio-alsa explicitement ? Donc par défaut, sous Arch Linux l’installation de pulseaudio (seul) ne fait pas le nécessaire pour que les applications utilisent PulseAudio automatiquement ?

Ben voilà, c’est exactement ce dont les utilisateurs se plaignent. C’est à ce moment-là qu’on leur dit de désinstaller PulseAudio, qu’ils constatent qu’après ça marche, et qu’ils en concluent que c’est à cause de PulseAudio que ça ne marche pas.

Malheureusement, il semble que sur les forums on trouve plus de gens pour dire « désinstalle PulseAudio » que pour dire « installe pulseaudio-alsa ». C’est con, et ce n’est pas vraiment de la faute de PulseAudio, mais c’est ce qui se passe.

Scoop : il n’y a pas que les outils fournis en standard avec ALSA. Si alsamixer ne te plaît pas, il y a plein d’autres mixeurs ALSA disponibles.

Chez moi j’utilise le mixeur de qastools, je ne sais pas s’il est compatible avec les « gens normaux » mais il me convient.

— Seulement si ALSA est configuré pour ça, ce qui manifestement n’est pas toujours le cas (sinon les multiples problèmes rapportés par des utilisateurs, se plaignant que depuis l’installation de PA leur programme préféré ne peut plus émettre de son, n’auraient pas lieu d’être) ;
— Vois ça comme tu veux, pour moi ça reste un contournement assez moche, par rapport à une situation idéale où toutes les applications utilisent PulseAudio volontairement.

Tu fais ça comment avec ALSA?

Faire quoi ? Avoir du son dans les haut-parleurs plutôt que dans le casque, sans avoir à débrancher celui-ci ? Ben tu coupes le canal « Headphone » et tu ouvres le canal « Speaker », pourquoi ?

C'est vrai, officiellement ? Source ?

Ben, ce n’est dit nulle part ainsi, mais c’est le principe d’un « serveur de son »…

PulseAudio se définit ainsi :

it is a proxy for your sound applications. It allows you to do advanced operations on your sound data as it passes between your application and your hardware. Things like transferring the audio to a different machine, changing the sample format or channel count and mixing several sounds into one are easily achieved using a sound server.

Il est évident que pour en profiter pleinement, il faut que tout le monde passe par ce « proxy ». Il suffit d’un seul programme qui décide de causer tout seul à ALSA indépendamment de PulseAudio pour perdre une grande partie de l’intérêt du serveur.

D’autant que comme ALSA ne permet pas à plusieurs programmes d’utiliser la carte son simultanément, tout programme voulant utiliser ALSA directement s’en verra empêché par la seule présence de PulseAudio (si ce dernier est déjà lancé, sinon c’est PulseAudio qui ne pourra pas accéder à la carte son).

C’est précisément à cause de ça que « désinstalle PulseAudio » est devenue la réponse archétypique (mais pas forcément bonne) aux problèmes de son. La situation typique, c’est qu’un utilisateur se plaint qu’un programme A n’émet aucun son (parce que PulseAudio est installé, tourne et monopolise la carte son, alors que le programme A, soit ne supporte pas PulseAudio, soit n’est pas configuré pour l’utiliser), il désinstalle PulseAudio, la carte son est désormais libre, le programme A fonctionne. Conclusion de l’utilisateur : PulseAudio c’est vraiment de la merde.

Avant, j'avais alsa, ça marchait, j'ai installé un jeu du Humble Indie Bundle qui m'a demandé PA, j'ai installé PA, joué, mes autres applis n'ont pas arrêté de m'emmerder pour le son, je suis revenu à alsa, ça tourne nickel.

Il faut aussi comprendre un peu le principe de PulseAudio. La situation idéale pour PulseAudio, c’est qu’il utilise seul la carte son et tous les autres programmes voulant émettre du son passent par lui. Si on installe PulseAudio au milieu d’un système dans lequel auparavant tous les programmes utilisaient ALSA directement, il est « normal » que cela pose problème, parce que tous les programmes doivent modifier leur comportement.

Il y a bien sûr des contournements, à la pasuspender, pour les programmes qui n’utilisent pas PulseAudio, mais ça reste des contournements. Le fonctionnement optimal de l’audio sur un système avec PulseAudio installé nécessite que tout le monde joue le jeu avec PulseAudio.

C’est un peu le problème avec les projets de Lennart Poettering, en fait : ils nécessitent une intégration complète dans la distribution pour fonctionner correctement.

Freeciv qui rame comme ce n'est pas permi (pour le rendu qui saccade alors que toute la logique est dans un serveur separe).

Pour ce que ça vaut, pour avoir essayé la version SDL et la version GTK du client Freeciv, chez moi il n’y a pas photo : la version SDL est effectivement terriblement lente, là où la version GTK est parfaitement fluide.

En pratique, comment sait-on quel serveur de son on utilise ?

Bah les deux principaux serveurs de sons sous GNU/Linux aujourd’hui sont PulseAudio et Jack. Les précédesseurs de PulseAudio, comme esd ou arts, sont obsolètes, et je doute qu’on les trouve encore sur des distributions un tant soit peu récentes.

Jack étant réservé à un usage particulier, tu ne peux pas vraiment l’utiliser sans le savoir. À ma connaissance aucune distribution généraliste ne l’installe par défaut (à juste titre), seules les distributions spécialisées dans la production musicale le font.

Quant à sndio, CoreAudio ou encore DirectSound, c’est facile, regarde si ton système d’exploitation est OpenBSD, Mac OS X ou Windows. ;)

Pourquoi pas, mais moi je pense que je m’en tiendrais à l’adage « n’attribuez pas à la malice ce que l’incompétence suffit à expliquer ».

Les développeurs du noyau Linux semblent très réticent à l’idée de permettre à des programmes en espace utilisateur d’accéder aux services de cryptographie du noyau, qui ne sont conçus que pour répondre aux seuls besoins internes du noyau.

Par exemple :

why we would ever want a userspace interface to [the Crypto API]?

Doing crypto in kernel for userspace consumers is simply insane.

Ou encore :

The Linux crypto-API is an internal kernel API used for things such as IPsec and dm-crypt. It's not directly usable by user-mode applications. […] In general, anything under the linux/ directory should not be used by ordinary applications directly. Anything in there you're allowed to use is re-exported under a sys/ include somewhere, and if it's a function it'll come with a manual page as well

Je ne crois pas que la clause de non responsabilité soit illégale car on la retrouve dans d'autres licences, propriétaires.

Alors là, je ne prendrais absolument pas ça comme une indication certaine de légalité de cette clause…

Des experts juridiques estiment que la GPL comme la BSD sont inadaptées au droit français, car la clause d'absence de responsabilité est illégale.

Si cette clause est illégale, alors de nombreux contrats de licence propriétaires (y compris ceux traduits en français) sont inadaptés aussi, non ? Je ne me souviens pas avoir vu un seul CLUF sans une telle clause.

Pourrais-tu m'expliquer comment passer de 76

Il suffit de savoir que 60 est le middle C, normalement C₄. 61 est C♯₄, 62 est D₄, 63 est D♯₄, etc. 76 devrait être E₅, mais apparemment l’auteur des commentaire considère que le middle C est C₅ et non C₄.

ce qu'est la vélocité ?

C’est une valeur de 0 à 127 indiquant une sorte « d’intensité » avec laquelle la note doit être jouée : plus la vélocité est élevée, plus la note doit être jouée avec force (fortissimo, en quelque sorte). Sur les contrôleurs MIDI à clavier, la vélocité traduit généralement la vitesse avec laquelle le musicien enfonce la touche.

j'ai du créer un facteur temps pour ralentir le tempo.

Je ne sais pas comment tu as créé ce facteur temps, mais normalement tu obtiens le tempo correct de la façon suivante :

Dans l’en-tête du fichier, il doit y avoir un champ « PPQN » (Pulses Per Quarter Note) indiquant le nombre de « battements d’horloge » par noire. Tous les temps dans le reste du fichier sont exprimés en battements d’horloge. Par exemple :

0:9/76/64/0/0-16:8/76/64/0/0

le message Note On est émis à t=0, et le message Note Off correspondant à t=16, soit 16 battements d’horloge plus loin. Si par exemple PPQN vaut 64 (64 battements d’horloge par noire), alors cette note a une durée de 16/64 ou 1/4 de noire, soit une double croche.

Ne reste plus qu’à connaître le tempo proprement dit. Il est indiqué par un ou plusieurs champs « TEMPO », exprimé sous la forme du nombre de microsecondes par noire (par défaut normalement dans un fichier MIDI, le tempo est de 120 noires par minutes, donc une noire dure 500 000 microsecondes). Dans l’exemple ci-dessus, la note doit donc sonner pendant 125 000 microsecondes.

---

Le format TSE3MDL semble être une transcription directe, en mode texte, du format binaire SMF (Standard MIDI File). Donc tu devrais trouver la réponse à la plupart de tes questions dans la documentation des standards MIDI et SMF (source officielle, et une très bonne référence officieuse).

Ce partage existait dès les fondements d'Internet et des BBS. Il était la règle implicite de tout logiciel écrit par des passionnés à cette époque, longtemps avant que RMS ne publie la première licence GPL.

Avec le temps sont apparues les licences, qui définissent explicitement les règles jusqu'alors implicite du partage de code de logiciel. Deux familles sont apparues:
* le partage à la GPL: tu dois reverses ton code à l'auteur si tu le modifies
* le partage à la BSD: fait ce qu'il te plait

Tu sautes une étape : on n’est pas passé tout de suite du partage implicite au partage codifié par les licences. Entre temps, il y a eu la propriétarisation des logiciels. Le partage est devenu l’exception plutôt que la règle, ce qui a justement rendu nécessaire l’utilisation de licence libre pour rendre explicite le partage qui était auparavant implicite.

Tu sembles dire que la GPL est une régression par rapport à l’époque enchanteresse des débuts. C’est peut-être vrai, mais dans ce cas ne t’en prends pas aux rédacteurs ou aux utilisateurs de la GPL. Ce ne sont pas eux qui ont tué le partage, mais ceux qui ont rendu les logiciels propriétaires à la base. Au hasard parmi d’autres, Bill Gates et sa fameuse « lettre ouverte aux hobbyistes ».

Lorsque je partage le code d'un logiciel que j'écris, je le partage avec plaisir. C'est un élan spontané vers les autres, et je ne mets pas de conditions à l'utilisation de mon logiciel. Si quelqu'un le trouve utile, j'en serai déjà très content. Si en plus, il le bidouille, c'est super, nous partageons peut-être une passion commune. Et si il lui vient l'envie à son tour de partager des modifications ou un autre logiciel avec moi, j'en serai ravi: il aura saisi l'esprit de notre communauté: l'enrichissement par le partage.

C’est très beau, mais vois-tu je doute que tu aurais pu convaincre Bill Gates avec ça.

Là ils disent : "There is one event per line in the form TIME:TOP/BOTTOM where TIME, TOP and BOTTOM are integer values. "

Time je peux comprendre, mais à quoi correspondent les top et bottom ? Quelqu'un a une idée ?

Tu ne regardes pas la bonne section de la documentation, le format de ces lignes est décrit dans la section « Phrase chunk », juste en-dessous :

There is one event per line in the form TIME:STATUS/DATA1/DATA2/CHANNEL/PORT where all values are integers. STATUS contains the MidiCommand status nybble, DATA1 and DATA2 contain the data bytes (which will not have bit 7 set), CHANNEL contains a value from 0-15 and PORT the computer MIDI port number to send the data on.

Ainsi :

0:12/26/0/0/0

est un message Program Change (STATUS = 12), où 26 est le numéro de programme ;

0:9/76/64/0/0-16:8/76/64/0/0 # E-6

est un message Note On, où 76 est la note à émettre et 64 sa vélocité, suivi du message Note Off correspondant

Tous ces messages étant émis sur le canal MIDI 0, sur le port MIDI 0.

Sur la page wikipédia d'Android on peut lire :
[…] Il s'agit d'une branche du noyau Linux 2.6, modifiée en vue de son utilisation sur des appareils mobiles. De cette branche ont été retirés le X Window System, les outils de GNU […]

Il faudrait corriger cette page, parce que cette formulation est pour le moins maladroite, voire carrément fausse : elle laisse entendre que X11 et les outils GNU font normalement partie du noyau Linux d’origine, et en ont été retirés pour Android… Certes, Linux est un noyau monolithique, mais pas à ce point-là. ;)

il n'est pas prouvé que la licence et/ou GNU ai été nécessaire au succès de Linux. Il n'est pas prouvé le contraire non plus certes. Perso je pense que c'est le tempérament (n'en déplaise à certains qui n'aiment pas) du Monsieur qui a été le plus structurant

À mon avis ce n’est ni l’un ni l’autre, c’est surtout les problèmes légaux dont souffrait BSD à l’époque (conflit entre AT&T et Berkeley sur la paternité du code et la marque UNIX, notamment).

L’avantage de GNU et de Linux c’est qu’il n’y avait aucun doute que leur code était original, sans aucun lien avec les systèmes Unix et assimilés pré-existants, et donc libre de tout danger juridique (c’était avant que SCO ne s’en mêle…). Un avantage qu’ils ne pouvaient avoir qu’ensemble : GNU sans Linux (et sans Hurd qui à l’époque était, euh, à peu près au même point qu’aujourd’hui en fait) dépendait d’autres noyaux pour être utilisable, et Linux sans GNU aurait très bien pu utiliser l’userland BSD mais les problèmes légaux sus-mentionnés l’auraient vraisemblablement privé du succès que l’on sait, comme ils en ont privé les BSD.

En définitive, c’était surtout une question de timing, le noyau Linux arrivant pile au bon moment, quand l’userland GNU était déjà bien complet et que personne n’osait miser sur BSD.

Je pensais plus à l'environnement dans lequel s'attend à évoluer

Dans ce cas, il faut être plus précis et ajouter une référence explicite à tout ou partie de cet environnement.

Android est ainsi une distribution Dalvik/Linux. Debian, Suse, RedHat, etc. sont des distributions GNU/Linux. Ton hypothétique « Windows 9 à noyau Linux » serait une distribution que l’on pourrait qualifier de « MS/Linux », et un hypothétique système utilisant un userland BSD sur un noyau Linux serait une distribution « BSD/Linux ».

Toutes ces distributions appartiennent à la superfamille des distributions Linux.¹ Mais la diversité de ces distributions fait que parler de « Linux » tout court est aujourd’hui trop vague. On pouvait s’en contenter à l’époque où le seul problème de cette appellation était qu’elle irritait RMS, mais à présent elle prête réellement à confusion, comme on le voit ici.

---

¹ Sauf les versions GNU/Hurd et GNU/kFreeBSD de Debian.