Wolfgang Draxinger a lancé le projet KLANG. Il ambitionne d'écrire un nouveau gestionnaire audio pour les noyaux Linux et FreeBSD avec un rendu professionnel :
- sans hachure,
- avec un minimum de latence
- et avec une gestion intelligente de l'énergie.
Alors que l'information est en train de se répandre sur la toile, l'auteur met en garde : bien qu'un site décrivant les ambitions du projet existe, le code n'est pas encore dans un état acceptable pour une première version publique.
Pourquoi avons-nous besoin d'un nouveau gestionnaire de son?
Selon l'auteur, aucune des solutions actuelles n'est pleinement satisfaisante.
Il y a d'abord l'ensemble des gestionnaires audio qui tournent en espace utilisateur: JACK, PulseAudio et ESD. Les processus en espace utilisateurs sont fortement dépendants de la charge en cours du système et sont donc tributaires du scheduler pour obtenir des ressources CPU. Or l'oreille humaine est capable d'entendre des "sauts" dans le son dès qu'un décalage de 4ms apparaît. En comparaison, l’œil a une tolérance plus importante car une désynchronisation jusqu'à 40 ms reste acceptable. Pour obtenir une bonne qualité de rendu de son, il faut donc pouvoir le traiter au plus proche du temps réel. Ceci n'est possible qu'en espace noyau.
Il existe actuellement deux solutions qui résident dans le noyau :
- ALSA : pas de mixage à la hauteur! L'API est compliquée et manque d'abstraction.
- OSS : l'API est bonne mais il ne gère pas les sources audio non échantillonnées (comme le MIDI). Il n'a pas non plus été pensé pour l'économie d'énergie et vide une batterie très efficacement. La conception de la gestion des signaux est moins intéressante que celle de JACK.
Partant de ce constat Wolfgang a décidé de prendre le meilleur de chacun des projets existants :
- la conception basée sur le routage de signaux comme JACK,
- l'API d'OSS,
- la gestion des sources non-échantillonnées,
- le code en espace noyau pour bénéficier des meilleurs latences possibles.
L'API d'OSS?
Il faut insister sur ce point. KLANG se présente aux applications au moyen de l'API existante d'OSS. Cela signifie que toute les applications gérant OSS prennent en charge KLANG ! Cependant, pour pouvoir gérer les fonctionnalités propres à ce nouveau gestionnaire, l'API originale sera étendue.
NdA : Nous souhaitons tous nos vœux de réussite à ce nouveau projet prometteur !
Aller plus loin
- KLANG official page (845 clics)
# Jack et le temps réel
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Bonjour,
Jack est supposé être adapté au temps réel/faible latence mais l'article semble dire que comme c'est en espace utilisateur, il y aurait aussi de la latence non acceptable sur Jack. Erreur ou est-on en train de dire que Jack ne fait en fait pas bien ce en quoi il est spécialisé?
Aussi on dit en général que Jack est adapté a un usage professionnel, mais que de toutes façons les non-pros ne se rendent pas compte de micro-coupures de sons (ce qui est faux. Sur mon ordi avec Pulseaudio, j'entend des micro-coupures dans la musique quand Skype fait un petit son), comme si l'utiliser aurait des désavantages pour le grand public. Est-on en train de dire qu'en fait il est possible d'avoir les deux? La qualité professionnelle (non latence, etc.) sans problème d'utilisation grand public flagrante? Si oui, ce serait génial!
Merci.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Jack et le temps réel
Posté par Michel Nicolas (site web personnel) . Évalué à 8.
JACK fait très bien son boulot de part son design. Il n'est pas dit qu'il y a de la latence avec JACK, mais qu'il consomme beaucoup de ressources CPU pour parvenir à ses fins. C'est donc très bien si on a une machine spécialisée, qu'on utilise spécialement pour le traitement du son : JACK pourra utiliser la majorité des ressources de la machines. Mais il consomme trop de ressources pour une utilisation desktop classique. Voici ce que dit l'auteur de KLANG :
[^] # Re: Jack et le temps réel
Posté par marc.collin . Évalué à -10.
l'optimiser pourrait être une solution au lieu de réinventez la roue
[^] # Re: Jack et le temps réel
Posté par reno . Évalué à 7.
Si tu lisais le journal, tu éviterais de faire des commentaires "bateau", JACK est en espace utilisateur, ce qui a un surcoût en latence donc pour compenser il faut diminuer la taille des buffers d'où une utilisation de CPU importante.
"L'optimisation" serait donc de mettre JACK dans le kernel, ce qui est un changement radical de conception, et il n'est pas sûr du tout que Linus accepterait d'intégrer le code (c'est vrai aussi pour KLANG)..
[^] # Re: Jack et le temps réel
Posté par un_brice (site web personnel) . Évalué à -6.
Quand à toi, tu devrais questionner ce que tu lit ;-) Augmenter la taille des buffers mange de la RAM, pas du CPU. Ou alors il y a une astuce mais c'est pas trivial et certainement pas juste écrit dans le journal.
Sinon, fondamentalement, ça semble être un problème d’ordonnanceur plus que noyau versus utilisateur (j'ai pas de chiffres mais franchement quelques changements de contexte ça semble super bon marché comparé à être préempté au mauvais moment). Et pour paraphraser l'auteur de Jack, ça fait longtemps qu'on fait plus le boulot dans les bottom halves des gestionaires d’interruptions. Je comprendrais que le gars défende un ou deux syscalls supplémentaire pour ordonner des trucs spécifique au scheduler (encore qu'à mon avis y'a déjà ce qu'il faut) mais là… j'ai du mal à interpréter son choix de conception autrement que comme une envie de garder l'API OSS en y rajoutant les fonctions modernes.
Mais je suis peut être mauvaise langue. On verra bien où ça nous mène.
[^] # Re: Jack et le temps réel
Posté par Zenitram (site web personnel) . Évalué à 10.
On parle de diminuer la taille des buffers. Buffers plus petits = plein de fonctions en cascades appelées plus souvent (ben oui, la taille du flux reste pareil, donc buffers plus petits = plus d'instance du buffer à gérer) avec son lot d'écritures dans les registres = plus de CPU consommé.
Perso, ça m'arrive d'avoir un ratio de 1 à 10 en conso CPU suivant la taille des buffers (pas exactement le même domaine mais le problème est pareil) que j'utilise en audio/vidéo. Le choix de la bonne taille de buffer est difficile (latence vs CPU).
[^] # Re: Jack et le temps réel
Posté par tchaik . Évalué à 0.
JACK ne crée PAS de latence supplémentaire, et ça n'a de toutes façons rien a voir avec le fait qu'il travail en espace utilisateur. C'est la taille du tampon et le taux d’échantillonnage qui influent sur la latence : latence ∝ taille_tampon / taux_échantillonnage.
[^] # Re: Jack et le temps réel
Posté par marc.collin . Évalué à -10.
c'est possible d'atteindre -10?
[^] # Re: Jack et le temps réel
Posté par Thomas Debesse (site web personnel) . Évalué à 0.
bientôt !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Jack et le temps réel
Posté par PapsOu . Évalué à -2. Dernière modification le 01 août 2012 à 20:19.
Tu vas bientôt le savoir ;-)
[edit] : arf de peu…
[^] # Re: Jack et le temps réel
Posté par Effraie (site web personnel) . Évalué à -10.
moi je me demande si c'est possible d'atteindre +10…
\Ö<
[^] # Re: Jack et le temps réel
Posté par Frank-N-Furter . Évalué à 5.
Il semble que non.
Depending on the time of day, the French go either way.
[^] # Re: Jack et le temps réel
Posté par Gabin . Évalué à -8.
Non, c'est le marketing du Libre, dés qu'un nouveau truc sort, le truc qu'il remplace qui était encensé et qui mettait la "loose" aux équvalents proprio est de fait reconnu comme bousin informe! Avec les défauts - auparavant ignorés, camouflés - bien mis en lumière histoire qu'on lui jette tous l'opprobre!
cf: n'importe quelle nouveauté du noyau qui remplace du code vénérable, éprouvé et encensé!
[^] # Re: Jack et le temps réel
Posté par Obsidian . Évalué à 10.
Moi, je suis étonné que personne n'ait encore fait de jeu de mot avec JACK / KLANG …
# OSS/ALSA
Posté par bilboa . Évalué à 3. Dernière modification le 01 août 2012 à 07:09.
C'est marrant j'ai toujours preferé l'API de ALSA moi ;-)
Ah oui, j'ai pas de mixer user-space aussi :)
[^] # Re: OSS/ALSA
Posté par Tonton Th (Mastodon) . Évalué à 5.
Alors c'est que tu fais partie des gens qui aiment l'ésotérisme abstractif dans les documentations.
[^] # Re: OSS/ALSA
Posté par Troy McClure (site web personnel) . Évalué à 4. Dernière modification le 03 août 2012 à 14:33.
moi j'ai une petite preferences pour les api qui sont bien documentées (cad certainement pas alsa)
# Paul Davis se fâche
Posté par tchaik . Évalué à 10.
Réaction de Paul Davis, développeur principal de Ardour (station audio-numérique à vocation professionnelle) :
> http://ardour.org/pd_on_klang
Le fil de discussion sur la linux-audio-mailing-list :
> http://lalists.stanford.edu/lau/2012/08/
[^] # Re: Paul Davis se fâche
Posté par foutaises . Évalué à 10. Dernière modification le 01 août 2012 à 11:23.
Wow, son billet est très critique envers Klang.
Pour les TL;DR : l'auteur de KLANG a non seulement une analyse fausse de l'état actuel de la situation mais aussi pris ses rêves pour des réalités sur la manière d'y remédier.
Le débat est trop technique pour mes compétences, mais en tant qu'utilisateur d'Ardour et de Jack, je sais que Paul Davis n'est pas un guignol. Son argumentation me semble d'ailleurs très factuelle et finalement assez loin des "je n'ai pas encore de code à présenter pour mon projet révolutionnaire mais ça va venir" qu'on a souvent vu fleurir sur linuxfr, pour souvent finir en comédie burlesque.
Il semble d'ailleurs rejoint dans son analyse par les autres contributeurs de la mailing list.
En tous cas très intéressant ce fil…
[^] # Re: Paul Davis se fâche
Posté par Guillaume Knispel . Évalué à 10.
C'est pas un guignol mais il ne faudrait pas non plus croire que son analyse (ou plutôt sa contre analyse) est pure est parfaite. Déjà rejeter de but en blanc les interrupts handlers sur OS généraliste tout en notant qu'au delà point de salut, c'est osé. Enfin bon ptet qu'il veut transformer Linux et FreeBSD en OS temps réel, qui sait ? Certes pour de l'audio pro ça ne reglera pas le problème de si plusieurs processus intéragissent et sont mal codés, mais c'est un peu enfoncer des portes ouvertes que de remarquer ça.
Pour la petite histoire j'écoutais des MP3 sans jamais avoir aucun lag du temps d'OSS avec une vielle SB sur port ISA, simplement avec des drivers de moins de 100k et sans bloat côté userspace. Autre temps, autres stacks : sur une machine de 2012 probablement 100x plus puissante et avec Pulse j'ai non seulemeent déjà eu des lags et des bugs, mais l'occupation CPU est ridiculement haute dans le processus Pulse. Et j'ai abandonné tout espoir de savoir quel est l'emprunte mémoire associée, entre Alsa en kernel space, Alsa en user space, Pulse et ses biblios.
Côté audio pro et Jack, je suis moins sûr du délire, mais l'état de la stack audio pour le desktop et les laptops n'est guère reluisant et vouloir proposer une alternative anti-bloat n'a rien d’infamant.
[^] # Re: Paul Davis se fâche
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
L'avantage principale a mes yeux de klang est d'être gérer dans le futur par l'équipe du noyau linux, cela permetra enfin d'avoir les drivers à jour et un système son identique présent partout.
Si des gens préfèrent les thread noyau au gestion par interruption, il faut en payer le prix en terme de latence, c'est justement cela qu'il faut éliminer ici. De plus, le problème des gestionnaires d'interruption précédent était d'être trop gros et de prendre trop de temps cpu, d'ou l'utilisation de thread noyau. Il faudrait donc que KLANG soit réentrant (correctement) sans lock, avec un temps d'execution court, et le gestionnaire de son sera réellement rapide et peu consommateur de ressouce.
"La première sécurité est la liberté"
[^] # Re: Paul Davis se fâche
Posté par B16F4RV4RD1N . Évalué à 10.
il me semble également que Paul Davis est l'auteur de Jack.
Je souhaite au projet Klang de réussir. L'audio sous Linux c'est compliqué. À part avec des trackers (schism tracker et compagnie), j'ai quasi abandonné la MAO sous Linux à cause de ça.
Pour info, mes notes pour me souvenir comment faire pour enregistrer le moindre petit truc en midi :
et pour jouer un son :
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: Paul Davis se fâche
Posté par gouttegd . Évalué à 3.
La complexité que tu décris est totalement indépendante du système audio utilisé. Elle découle uniquement de la volonté typique des développeurs unixiens de favoriser de multiples programmes travaillant ensemble plutôt qu’un seul programme faisant tout (comme on en trouve sur Windows ou Mac OS, dans le genre de Cubase, Sonar, Logic…).
Remplace l’ensemble {ALSA,CoreAudio,OSS}+Jack par Klang, la situation sera exactement la même (les développeurs ne vont pas se mettre à faire des applications monolithiques pour autant), sauf qu’au lieu de connecter des entrées/sorties Jack, tu connecteras des entrées/sorties Klang.
[^] # Re: Paul Davis se fâche
Posté par Pierre Tramonson . Évalué à 1.
En gros c'est merdique pour les utilisateurs, mais c'est super pour les développeurs qui se font plaisir à faire de belles couches techniques, de beaux patterns et des APIs sexys (et encore… si seulement c'était vrai).
[^] # Re: Paul Davis se fâche
Posté par Sathors . Évalué à 2.
Hum, c'est assez marrant comme remarque pour un linuxien … Il me semblait qu'en gros c'est un peu le délire de linux, d'avoir pleins de petits programmes qui font les choses bien à la place de logiciels monolithiques qui sont beaucoup plus durs à maintenir, plus problématique en cas d'abandon, etc.
Alors c'est sûr ça demande un petit peu plus de boulot de la part de l'utilisateur, mais ça les vaut bien !
Moi perso j'aime assez.
[^] # Re: Paul Davis se fâche
Posté par Zenitram (site web personnel) . Évalué à 10.
Non, ça ne le vaut pas, sauf exception de quelques masochistes. Et même sous Linux, certains savent faire des outils qui ne demandent pas du boulot inutile à l'utilisateur. Le problème n'est pas Linux en lui-même, mais les développeurs qui pensent que l'utilisateur va faire un effort alors que l’utilisateur veut… utiliser. Ceux qui ont les utilisateurs sont ceux qui permettent à l’utilisateur d'utiliser.
[^] # Re: Paul Davis se fâche
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
En plus, une personne peut créer un draksoundstudio qui permet en quelques clic de tout mettre en place.
"La première sécurité est la liberté"
[^] # Re: Paul Davis se fâche
Posté par Marotte ⛧ . Évalué à 6.
C'est surtout celui d'UNIX à la base donc on retrouve ce "délire" dans tous les OS de cette grande famille…
[^] # Re: Paul Davis se fâche
Posté par Michel Nicolas (site web personnel) . Évalué à 2.
Ce n'est pas un délire ni lié à Linux. Cela s'appelle KISS:
[^] # Re: Paul Davis se fâche
Posté par B16F4RV4RD1N . Évalué à 3.
autant j'adore les |, autant je trouve cette mise en place avec jack et ses copains plutôt fastidieuse, notamment parce qu'il ne me semble pas possible de scripter cela facilement. Peut-être qu'au lieu de l'interface graphique qjackctl on peut utiliser autre chose pour faire certaines connexions, mais dans la plupart des programmes, par exemple qsynth, on est obligé tout de même de configurer les connexions à la main, à chaque fois (ou alors j'ai raté un truc).
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: Paul Davis se fâche
Posté par gouttegd . Évalué à 10.
Oui, tu as raté un truc. Deux, en fait.
D’une part, il est parfaitement possible de scripter les connexions, il suffit d’appeler jack_connect(1) dans un script.
D’autre part, pour ceux qui ne veulent pas avoir à faire un script pour ça (moi par exemple), QJackctl permet de créer et d’enregistrer autant de configurations que l’on souhaite (c’est l’outil « Patchbay »), que l’on peut ensuite activer d’un simple clic.
Combiné à la possibilité de lancer automatiquement un programme au lancement de Jack, ça me permet de démarrer mon studio virtuel en deux étapes : ① lancer QJackctl, ② cliquer sur « Start » pour démarrer Jack. Cela lance automatiquement, non seulement Jack, mais aussi Rosegarden, ZynAddSubFX et Ardour (les trois programmes que j’utilise, on pourrait en ajouter d’autres comme Hydrogen, Bristol, etc.) ; les connexions pré-enregistrées dans le PatchBay de QJackctl sont automatiquement mises en place, et le tout est immédiatement utilisable.
En passant, c’est quelque chose que je n’ai jamais réussi à faire avec un mastodonte tout-en-un comme Cubase VST. Il n’y a certes qu’un seul programme à démarrer, mais il y avait toujours une série de manipulations à faire avant qu’il soit prêt à enregistrer quoi que ce soit. Un programme monolithique n’est pas nécessairement plus facile à utiliser…
[^] # Re: Paul Davis se fâche
Posté par B16F4RV4RD1N . Évalué à 5.
merci, je vais regarder ça
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: Paul Davis se fâche
Posté par Thomas Debesse (site web personnel) . Évalué à 4. Dernière modification le 05 août 2012 à 17:25.
tu peux aussi regarder le projet Ladish, il t'intéressera très certainement : tu peux créer des "studios" en précisant les logiciels et les routages… Donc après ça tu peux démarrer un studio (ça lance les logiciels et ça route), ou l'arrêter (ça ferme les logiciels et défait les routages), puis aussitôt tu démarre un autre studio… c'est très prometteur !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Paul Davis se fâche
Posté par Arathor . Évalué à 1.
Et il se passe quoi pour regarder une vidéo avec mplayer ? Il faut faire une route à la main pour chaque appli qui produit du son ?
[^] # Re: Paul Davis se fâche
Posté par Thomas Debesse (site web personnel) . Évalué à 4.
Non, la plupart de ces programmes savent se router tout seul. Je n'ai pas Mplayer sous la main mais mais je suis certain qu'avec VLC et Gstreamer ça se fait tout seul. Donc quand tu configure Jack en autoconnect comme système audio Gstreamer, toutes tes applis Gstreamer (rhythmbox, totem, pitivi, etc.) savent se connecter toutes seules.
Ladish ne sert pas à ça, ladish sert à faire d'autres montages, avec Jack on peut choisir de faire autrement !
Jack a des défauts mais pas ceux là. Si ton mplayer lit dans le vide sans être connecté à une carte son, c'est un défaut d'intégration, pas un défaut de Jack. Je suis certain qu'en fournissant pour Jack un effort d'intégration similaire à ce qui est fait pour PulseAudio, Jack pourrait être utilisé par le tout venant sans qu'il le sache.
Par exemple, quand tu as plusieurs cartes sons, PulseAudio te connecte ton appli son sur une de ces cartes sons, pourquoi celle-là ? Il y a toute une logique avec une interface de configuration accessible au tout venant pour dire quelle est l'interface par défaut, et laquelle pour tel programme. Et puis il y a une règle par défaut "si l'utilisateur n'a rien dit, alors c'est connexion automatique sur la première carte son". On pourrait faire la même chose avec Jack, mais ce n'est pas fait, mais ce n'est pas la faute de Jack, c'est un défaut d'intégration.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Paul Davis se fâche
Posté par foutaises . Évalué à 5. Dernière modification le 02 août 2012 à 11:14.
Ton workflow est effectivement complexe.
J'avoue ne pas toucher au midi, mais pour donner un autre exemple mon besoin est le suivant :
Enregistrer sur adour des pistes de guitare et de basse, avec accompagnement boite à rythme et partition synchronisée qui défile sous mes yeux.
Voici mon process :
Là j'ai les trois logiciels qui démarrent en même temps : la batterie en fonds, enregistrable ou non.
Si je veux refaire une partie au milieu du morceau, je me positionne sur la bonne mesure dans tuxguitar sans me préoccuper des deux autres softs qui vont automatiquement s'aligner sur le bon moment. (je pourrais très bien le faire depuis hydrogen au besoin).
Franchement, une fois le concept de jack assimilé, je trouve ça personnellement très facile et très puissant. Je mets plus de temps à faire les branchements physiques qu'à mettre en place le studio virtuel.
Précision, je n'avais aucune connaissance en MAO préalable, et les tuto ne sont franchement pas légion.
[^] # Re: Paul Davis se fâche
Posté par foutaises . Évalué à 4.
Relisant ton commentaire je souhaite revenir sur ton workflow (et je viens de dépasser le temps d'edition alloué par linuxfr).
Jack est là pour donner la base d'un studio virtuel. En gros (pour les béotiens) tu as des entrées et des sorties de tout type que tu relies comme si tu branchais physiquement un appareil à un autre.
Je ne vois pas comment une alternative pourrait décider pour toi si ton midi sort par ta carte son principale, par ton casque ou ta mixette.
Pour les réglages de qjackctl je n'utilise pas le 48k mais plutôt le 41,1K. Dans tous les cas, j'ai enregistré deux profils (mixette branchée, mixette pas branchée) qui me permettent de ne plus configurer mon serveur.
Enfin, Jack/ardour se veulent des outils destinés à des utilisations "pro". Sur une machine dédiée, la quasi totalité de tes étapes sauteraient. Ca se compléxifie quand tu utilise ta machine aussi bien pour faire de l'enregistrement haute qualité/temps réel que pour regarder un film via alsa sur VLC… ça ne me semble pas anormal.
[^] # Re: Paul Davis se fâche
Posté par Marotte ⛧ . Évalué à 3.
Faire sortir le MIDI par le casque c'est une excellente idée ;)
[^] # Re: Paul Davis se fâche
Posté par B16F4RV4RD1N . Évalué à 3.
effectivement, si la machine était dédiée à cela, avec la carte son qui va bien, ça irait sans doute mieux. J'ai de toute façon prévu d'acheter une carte son usb prochainement, en suivant les conseils de linuxmao.
en tout cas, j'aurais bien aimé avoir plus de possibilités pour sauvegarder des configurations (préselections) par exemple.
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: Paul Davis se fâche
Posté par jihele . Évalué à 1.
Sur linuxmao, on m'a déconseillé… l'USB.
J'ai une carte FireWire. Inconvénient, elle ne fonctionne qu'avec Jack donc je ne l'utilise que pour la MAO et le reste du temps je sors sur la carte intégrée. Ça fait une petite manip supplémentaire.
[^] # Re: Paul Davis se fâche
Posté par Marotte ⛧ . Évalué à 2.
Pourquoi ? Source ?
Le bus USB est largement capable de transférer mettons 2x2 voies en 48kHz, quel est le problème avec l'USB au juste ?
[^] # Re: Paul Davis se fâche
Posté par jihele . Évalué à 2.
J'ai cherché le message en question mais j'ai pas retrouvé…
L'idée serait (pas taper si je me trompe, je ne fais que répéter, et peut-être mal en plus) que l'USB 2 serait mal "standardisé" avec les fabricants qui n'en font qu'à leur tête et que donc avec un périph en USB 2 on aurait des perfs USB 1 de toute façon.
Dit comme ça, ça ressemble à une hérésie, mais peut-être que ça dira quelque chose à quelqu'un qui saura corriger et j'ai pas le temps de creuser.
En tout cas un utilisateur du forum qui avait l'air sûr de lui affirmait que pour éviter la latence, PCI(e) > FW > USB
[^] # Re: Paul Davis se fâche
Posté par Marotte ⛧ . Évalué à 1.
Les fabricants n'en font toujours qu'à leur tête !
S'il avait l'air sûr de lui alors ! :)
C'est sûr qu'une carte en PCI(e) va pouvoir se taper des latences de ouf de l'ordre de la dizaine de nanoseconde mais ça n'a aucun intérêt ! En audio une latence inférieure à 4 ms suffit. Donc entre une carte PCI premier prix et une carte USB avec des DAC de qualité j'hésite pas une seconde…
[^] # Re: Paul Davis se fâche
Posté par Alex . Évalué à 2.
je ne suis ni un pro du hard ni de l'audio, néanmoins ile me semblait que le problème avec l'usb était l'incapacité des périphériques d'interrompre la machine lorsqu'ils ont besoin de quelque chose. C'est en effet l'hôte qui doit demandé périodiquement à chaque périph si il a quelque chose à faire (enfin c'est à peu près ça, de mémoire il y a un mode asynchrone pour les periphs type clavier/souris, mais ne permettant pas de débits important).
Ceci dit je doute que la latence que cela provoque soit à ce point notable
[^] # Re: Paul Davis se fâche
Posté par B16F4RV4RD1N . Évalué à 3.
effectivement, apparemment il vaut mieux éviter l'usb2.
J'avais vu cette carte usb (1 ou 2, je ne sais pas, sans doute 1), qui semble bien fonctionner sous Linux :
http://tuxicoman.jesuislibre.net/2009/03/audiobox-usb-sur-linux.html/comment-page-1
De toute façon ma tour est trop petite pour rajouter une carte son, donc je n'ai pas le choix, c'est usb ou rien.
Et puis le firewire est difficilement trouvable de nos jours
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: Paul Davis se fâche
Posté par jihele . Évalué à 2.
En effet j'avais failli acheter ça. Elle se vend aussi en kit avec casque et micro.
Tu veux dire la carte son ou le port sur le PC ?
Finalement j'ai pris une Focusrite Saffire ("l'originale" (façade blanche)) en FW. Effectivement, elle ne se vend plus, je l'ai trouvée d'occasion. Avant de choisir FW, bien consulter le site de ffado, voire se renseigner sur la liste de discussion utilisateurs car le site est pas forcément à jour : certains matériels fonctionnent sans que ça soit bien indiqué.
[^] # Re: Paul Davis se fâche
Posté par gouttegd . Évalué à 3.
Il faut bien se renseigner aussi sur le contrôleur FireWire présent sur le PC, tous ne se valent pas et certains sont même catastrophiques pour une utilisation en MAO.
Les choses ont peut-être changé depuis, mais il y a quelques années (2006), l’opinion répandue parmi les MAOistes était, en gros, que les contrôleurs Ricoh sont daubesques tandis que les Texas Instruments sont ce qui se fait de mieux. Je ne peux pas confirmer pour les Texas Instruments, mais effectivement les performances de mon contrôleur Ricoh étaient assez pitoyables (aussi bien sous Windows que sous Linux, donc ce n’était pas un problème de pilote).
[^] # Re: Paul Davis se fâche
Posté par jihele . Évalué à 2.
Oui, bonne remarque. J'avais oublié. Et comme il est difficile de tirer des règles générales, ça peut valoir le coup de se renseigner aussi sur la liste des utilisateurs avant l'achat.
[^] # Re: Paul Davis se fâche
Posté par psychoslave__ (site web personnel) . Évalué à 4.
Je me suis paluché la doc de jack (qui parle surtout de son fonctionnement interne, ce qui est intéressant, mais pas pour l’utilisateur) et j’ai essayé de trafiqué un moment pour faire fonctionner de concert jack/ardour/hydrogen/tuxguitar et au final j’ai toujours eu une couille quelque part.
Je suis peut être une buse, mais c’est pas la volonté qui me manquait, pourtant y a un moment t’as envie que ça fonctionne et pas te prendre la tête à faire de la configuration logiciel. J’ose pas imaginer l’horreur pour un utilisateur normal.
Si tu as des liens vers des tutos pas à pas pour les grosses buses comme moi, je suis preneur.
[^] # Re: Paul Davis se fâche
Posté par Tonton Th (Mastodon) . Évalué à 2.
C'est vrai que rajouter encore une couche/abstraction/machin, ça va bien simplifier les choses…
[^] # Re: Paul Davis se fâche
Posté par Olivier Serve (site web personnel) . Évalué à 2.
Ce n'est pas ajouter, c'est remplacer. Par quelque chose de (supposément) plus adapté.
[^] # Re: Paul Davis se fâche
Posté par Flo_ . Évalué à 1. Dernière modification le 08 août 2012 à 23:57.
Ah c'est drôle, moi mes notes c'est :
- lancer GLadish
- jouer
Et oui, ça a bien progressé depuis ;)
Flo
[^] # Re: Paul Davis se fâche
Posté par reno . Évalué à 10.
Je suis intervenu sur la mailing list de Phoronix, car certains points de Paul Davis me paraissaient un peu "rapide":
En résumé je trouvais que bien que la mémoire partagée n'utilise pas d'appel système mais qu'il faut bien utiliser des IPC en plus et que le tout 'pull' ne me parait pas satisfaisant dans tout les cas (jeux par exemple) et donc des modifs du kernel pourraient être intéressant.
Et bien il m'a répondu fort poliment:
http://phoronix.com/forums/showthread.php?72625-KLANG-A-New-Linux-Audio-System-For-The-Kernel&p=278764#post278764
Apparemment quasiment tout les points de l'auteur de KLANG m'ont l'air mort, mais il y aurait quand même quelque chose a faire: Paul Davis trouverait super d'avoir une modification d'ALSA pour supporter aussi une interface à la CoreAudio..
Si je ne me trompes pas ça revient à importer une partie de ce que fait PulseAudio dans le kernel pour une meilleure efficacité..
Dommage que l'auteur de KLANG n'ai pas eu cette discussion avec Paul Davis avant de démarrer KLANG, ça aurait pu être un projet intéressant!
# Je vois plusieurs difficultés:
Posté par reno . Évalué à 4.
Sa description du projet KLANG est intéressante, mais il y va y avoir plusieurs difficultés:
- le module KLANG utilisera probablement des calculs flottants donc l'intégrer dans le kernel Linux sera "mission impossible"TM.
Bref j'ai l'impression que s'il va au bout son projet devrait avoir du succès dans le monde BSD mais dans le monde Linux ça m'étonnerait..
[^] # Re: Je vois plusieurs difficultés:
Posté par dguihal . Évalué à 2.
Pour les calculs flottants autant le x87 n'est pas dispo de base, mais le sse devrait l'être non ? Alors oui ça suppose que les vieux CPU ne feront pas tourner KLANG, mais bon le SSE ça date de 99 maintenant c'est plutôt répandu comme jeu d'instruction CPU.
Pour les autres archis par contre je n'ai aucune idée de comment ça se passe …
Et pour l'API OSS y'aura qu'a wrapper PulseAudio dessus /o\
[^] # Re: Je vois plusieurs difficultés:
Posté par reno . Évalué à 3.
Ce n'est pas un problème de disponibilité du calcul flottant sur le CPU, c'est la possibilité/l'autorisation d'utiliser ces instructions dans le noyau Linux qui est le problème: les devs de Linux interdisent d'utiliser le calcul flottant dans le noyau si mes souvenirs sont bon, ce qui n'est pas le cas du noyau FreeBSD.
[^] # Re: Je vois plusieurs difficultés:
Posté par reno . Évalué à 6.
Ceci dit j'ai tout faux sur l'utilisation du calcul flottant dans sa réponse à Paul Davis, le développeur de KLANG donne plus de précision: KLANG utilisera du calcul entier pour faire le muxing, cf sa réponse dans le lien donné par tinram (merci): http://ardour.org/pd_on_klang
Apparemment ils ont décidé de continuer à en discuter sur phoronix, dommage vu la qualité des "contributeurs" de Phoronix (à peu près un gars qui cherche a comprendre le sujet pour 10 trolleur), ça ne devrait pas aider.
Bon je ne suis pas qualifié pour commenter les remarque de Paul Davis, mais je ne vois pas comment une implémentation dans le kernel peut être moins efficace que de l'inter-application audio à moins qu'ils utilisent de la mémoire partagée et encore la mémoire partagée ce n'est pas suffisant: il faut aussi utiliser des instructions de synchronisation qui passent par le kernel, alors..
[^] # Re: Je vois plusieurs difficultés:
Posté par Troy McClure (site web personnel) . Évalué à 4.
Dans le thread sur ardour.org il precise que tous les buffers et le mixage seront en entiers 32-bits.
[^] # Re: Je vois plusieurs difficultés:
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Pas en entier 64 bits ? Mixer des échantillions 24 bits, avec des entiers 32 bits sans perte est assez compliqué.
"La première sécurité est la liberté"
[^] # Re: Je vois plusieurs difficultés:
Posté par Zenitram (site web personnel) . Évalué à 3.
C'est pas non plus une table de mixage qui est demandée, mais de mixer la musique + les sons système par exemple, avoir 8 bits "de réserve" est amplement suffisant. Déjà que pas foule détecte la différence entre 16 et 24 bits…
[^] # Re: Je vois plusieurs difficultés:
Posté par Shuba . Évalué à 5.
Mais linux sert pour des tables de mixage.
[^] # Re: Je vois plusieurs difficultés:
Posté par Jux (site web personnel) . Évalué à 3.
En fait comme Paul Davis le souligne dans la discussion, s'il veut remplacer le système de sons du noyau alors oui, il faut prendre en compte des cas ou il y a plus de 256 entrées ou des contraintes de qualité. Sinon, autant garder ce qui existe.
Par contre un système en mode utilisateur (genre Pulseaudio) peut tout à fait être orienté utilisateur "lambdas" et avoir un autre système pour les pros.
[^] # Re: Je vois plusieurs difficultés:
Posté par reno . Évalué à 5.
Ton commentaire n'est pas faux, mais Paul Davis précise que le système en question n'utilise pas ALSA donc pour ce cas précis ça n'est pas un problème, mais je suis d'accord: dans le cas générique le calcul entier ça pose des problèmes.
Aussi Paul Davis précise qu'il y a deux façons d'avoir des systèmes audio: le pull (la carte son annonce qu'elle a besoin de données supplémentaire et les applis fournissent), le push: les applis fournissent les données et précise que le pull est le plus répandu et qu'avec une bufferisation ont peu faire du push sur du pull mais pas l'inverse.
Sauf que une appli voulant 1) que le son prenne peu de ressources 2) avoir quand même une faible latence (par exemple un jeu) ne me parait pas bien servi par ni par un pull (car pour la faible latence il faut définir des buffers de petite taille donc beaucoup d'interruption) ni par un push bufferisé sur du pull, donc un kernel qui fasse du pull (parfait pour les applis pro de multiplexage) et du push (bien pour les jeux) ça ne me choquerait pas..
Après je ne suis pas spécialiste en audio!
# Que de bruit
Posté par Zarmakuizz (site web personnel) . Évalué à 10. Dernière modification le 01 août 2012 à 09:52.
Il y a cinq mois : le projet a déjà démarré
Il y a quelques jours : sur le site d'actualités Heise.de, il parle de son projet et laisse un bookmark pour ceux qui sont intéressés par l'évolution du projet.
Juste après ça : l'info est postée sur Reddit, créant un ramdam que Wolfgang Draxinger ne s'attendait pas à avoir.
Hier : l'auteur de Jackd dit que c'est un désastre audio supplémentaire, parce que les problèmes sont ailleurs, parce que Jack fait déjà le café, parce que le site mis en place n'a quasiment aucune info même pas sur l'auteur (Note: le site était fait à la Rache© pour pouvoir donner un bookmark sur la page des news). Paul Devis et Wolfgang (datenwolf) discutent sur Phoronix.
(EDIT: déjà posté plus haut, mais je n'ai pas vu la substance de la mailing list, le topic sur phoronix a peut-être une valeur ajoutée ou pas.)
Pour en savoir plus sur le personnage, il a entre autres donné une conférence où il s'est disputé avec Lennart Poettering en direct, mais je ne peux pas regarder des vidéos au boulot donc je vous laisse juger.
Les liens sont sympas à parcourir, ça parle sur Phoronix de pourquoi le paradigme utilisé sur OS X est le plus mieux bien, et dans les commentaires sur Reddit j'ai trouvé ça :
La semaine est placée sous le signe du Gnome on dirait.
Sur une note moins trollesque :
J'arrête de lire, faudrait que j'increase ma productivity au boulot.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Que de bruit
Posté par devnewton 🍺 (site web personnel) . Évalué à 9.
Apparemment ni Windows, ni Mac OS X ne sont prêt pour le desktop audio exigent!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Que de bruit
Posté par Mathias Bavay (site web personnel) . Évalué à 3.
Quelque part, ma première réaction, c'est "pourquoi? Car l'audio recommence à vaguement marcher, donc il est temps de tout casser une fois de plus". Après cet aperçu, je me dis que le projet va peut être faire un flop et nous éviter un nouveau cycle de bugs sur l'audio le plus basique…
Mathias
[^] # Re: Que de bruit
Posté par Tom D . Évalué à 3.
Ouch, j'avais vu cette vidéo, très intéressant au final grâce à Lennart mais ça montre un Wolfgang qui croit avoir tout compris alors qu'il est pratiquement toujours à côté de la plaque.
J'avais trouvé le projet "Klang" intéressant à la première lecture, mais du coup, dans la série des "projets prometteurs qui ont encore du chemin à faire", je retourne vers Wayland.
Tom
[^] # Re: Que de bruit
Posté par Jux (site web personnel) . Évalué à 9. Dernière modification le 02 août 2012 à 10:21.
Après avoir vu la vidéo et lu une partie de la discussion sur phoronix, ce type semble avoir une sérieuse tendance à dire que des systèmes qu'ils ne comprend pas sont pourris.
Dans la vidéo, il trash pulseaudio, gdm, policykit et dbus et à chaque fois Lennart démontre que ses arguments ne tiennent pas. Bref, il passe pour un guignol qui a bâtit son talk sur un fil de discussion Linuxfr sans faire plus de recherches.
Sur le forum, il se justifie en disant qu'il vient de la physique expérimental et qu'il fait plein de signal processing avec des gros signaux au boulot… et ensuite Paul Davis démontre à nouveau qu'il parle de quelque chose qu'il ne connaît pas et qu'il n'a aucune expérience dans le monde audio (ce qui est quand même un peu bizarre quand on propose de tout réécrire).
Bref, ça inspire pas trop confiance.
# Tout dans le kernel?
Posté par claudex . Évalué à 8.
Il me semblait que la principale raison pour laquelle OSS n'entrerait jamais dans le kernel est qu'il faisait trop de chose en espace noyau. Comment espère-t'il rentrer dans le kernel s'il de porte tout dedans pour gagner en performances?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Tout dans le kernel?
Posté par reno . Évalué à 5.
Pas sûr que ça soit la vrai raison, ça peut être lié à l'histoire d'OSS dans Linux aussi..
[^] # Re: Tout dans le kernel?
Posté par Michel Nicolas (site web personnel) . Évalué à 4.
Il semble que OSS a été abandonné à l'époque au profit de ALSA pour des problèmes de licence.
[^] # Re: Tout dans le kernel?
Posté par MTux . Évalué à 1.
La tendance chez Linux est de tout rapatrier dans le kernel, comme pour KMS.
Du coup je pencherai plutôt pour une histoire de licence afin d'expliquer qu'il aie été mis à part.
# Comme d'habitude, l'image de référence
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
[^] # Re: Comme d'habitude, l'image de référence
Posté par Marotte ⛧ . Évalué à 10.
C'est dingue de voir le nombre de fois que ce strip est cité ici sur linuxfr :)
[^] # Re: Comme d'habitude, l'image de référence
Posté par warwick . Évalué à -5.
Tu veux pas plutôt dire le nombre de fois ou ce strip est hyperlinké ou inséré?
Je l'ai vu au moins deux fois cette semaine, sur des sujets différents, et on n'est que mercredi…
[^] # Re: Comme d'habitude, l'image de référence
Posté par Marotte ⛧ . Évalué à 10.
Oooohhhhh ! Toi tu vas pas commencer à jouer avec mes couilles ! :)
[^] # Re: Comme d'habitude, l'image de référence
Posté par warwick . Évalué à -1.
Pourquoi? T'as peur qu'elles se détachent ?
Sur ce, bon moinssage!
Coin coin
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Comme d'habitude, l'image de référence
Posté par Marotte ⛧ . Évalué à 5.
Pour te répondre plus sérieusement. Je pense que le verbe citer dans le contexte du web s'applique à l'insertion d'une image, d'une vidéo, parce que le web le permet. En effet citer dans un sens plus classique, par exemple écrire : "Ça me rappelle le xkcd numéro 42 qui traite de la multiplication des standards" est parfaitement inutile, vu que l'on peut directement insérer la substance proprement dite…
D'où ma réaction ;) (certains je pense auront reconnu le passage d'un dialogue du film Dikkenek)
[^] # Re: Comme d'habitude, l'image de référence
Posté par Gabin . Évalué à -4.
C'est d'ailleurs grâce à cette analogie que Google est né :). Larry Page partait du postulat qu'un lien représentait une citation.
[^] # Re: Comme d'habitude, l'image de référence
Posté par warwick . Évalué à 1.
Cette histoire testiculaire est donc en fait un malentendu:
Je ne discutais du tout pas le terme "cité", mais le fait qu'on trouve ce strip beaucoup seulement sur linuxfr. Ce strip apparait a tout bout de champ sur un nombre impressionnant de sites, à propos de beaucoup trop de sujets (dans le sens ou malheureusement, oui, il y a beaucoup trop de raisons valables pour le citer.)
P.S.: Passe le bonjour a tes bourses !
[^] # Re: Comme d'habitude, l'image de référence
Posté par Marotte ⛧ . Évalué à 1.
o_O
Quand on veut donner son avis on écrit ce qu'on pense hein. Donc désolé de te dire que si, tu discutais un terme. Tu avais autre chose en tête certes mais on peut pas le deviner…
Je l'ai vu au moins deux fois cette semaine, sur des sujets différents, et on n'est que mercredi…ne signifie en rienon trouve ce strip beaucoup seulement sur linuxfEffectivement je l'ai jamais vu hyperlinké (beurk…) sur d'autre sites.
[^] # Re: Comme d'habitude, l'image de référence
Posté par zebra3 . Évalué à 9.
À chaque fois qu'il est posté on se tape un +10, alors j'en profite :-)
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Comme d'habitude, l'image de référence
Posté par Ph Husson (site web personnel) . Évalué à 9.
Ce qui est dingue c'est à quel point il est vrai …
[^] # Re: Comme d'habitude, l'image de référence
Posté par Reihar . Évalué à 1.
C'est Rendall quoi.
[^] # Re: Comme d'habitude, l'image de référence
Posté par Tony Flow . Évalué à 5.
A se demander si ce n'est pas ce strip qui a poussé l'équipe de LinuxFr à mettre en place un système de cache !
[^] # Re: Comme d'habitude, l'image de référence
Posté par B16F4RV4RD1N . Évalué à 2.
c'est clair que sur microsoftfr il n'y a qu'un seul standard valide, le leur, alors ce genre de strip est plus pertinent dans un contexte de logiciels libres.
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
# OSS: l'API est bonne
Posté par Benoit Jacob (site web personnel) . Évalué à 5.
Quoi?!
A la rigueur, "OSS117 : l'API est bonne", ca pourrait faire un bon mot de passe. A part ca, on est bien d'accord qu'on parle de l'API "tout est un fichier et pour lire un son il suffit de l'envoyer sur /dev/audio" ? "Tout est un fichier" est l'un des principes inalienables d'UNIX decides un jour par un barbu dans les annees 70. Comme disait OSS justement, "vous vous en lasserez… va falloir se decider a grandir!"
[^] # Re: OSS: l'API est bonne
Posté par illogict . Évalué à 9.
Le nombre de fois où l'on faisait des
cat /dev/urandom > /dev/dsp(ou /boot/vmlinuz pour pouvoir dire au p'tit nouveau qu'il « écoutait son kernel ») dans des install-party (il y a de cela quelques années, hein) pour vérifier rapidement que l'audio était fonctionnelle est incommensurable.[^] # Re: OSS: l'API est bonne
Posté par Sufflope (site web personnel) . Évalué à 10.
Avec la parenthèse placée là, on comprend cat /dev/urandom > /boot/vmlinuz, et ça fait vieil enculé.
[^] # Re: OSS: l'API est bonne
Posté par Ben Doumenc (site web personnel) . Évalué à 6.
Encore mieux pour écouter son kernel: http://www.linux.fm/
[^] # Re: OSS: l'API est bonne
Posté par Guillaume Knispel . Évalué à 2.
C'est vrai que Win32 c'est quand même mieux que cette API de l00ser utopiste ou tout est fichier.
[^] # Re: OSS: l'API est bonne
Posté par Benoit Jacob (site web personnel) . Évalué à 1.
Ben oui, evidemment, puisque l'API "Win32" en question, c'est DirectSound. Je n'avais pas encore vu quelqu'un nier que c'est mieux qu'OSS.
[^] # Re: OSS: l'API est bonne
Posté par Batchyx . Évalué à 5.
Il y a à peu près autant d'API dépréciée pour lire du son sous Windows et sous linux. Et DirectSound en fait partie, de ces API dépréciée, tout comme MCI et DirectMusic.
[^] # Re: OSS: l'API est bonne
Posté par B16F4RV4RD1N . Évalué à 6.
J'adore me beurrer la kernelle, mais pas avec du flan Alsa.
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
# Popcorn
Posté par Maclag . Évalué à 10.
Après avoir connu la longue migration Alsa, parce que OSS, faut pas déconner, c'était trop pas bien
Après avoir connu la douloureuse introduction de Pulseaudio, qui porte bien son nom: l'audio marche suivant une fonction pulse: "marche… marche pu… marche… marche pu… euh… marche??".
Après avoir vu tout le monde gueuler dans tous les sens que l'audio sous Linux c'est le gros bordel, alors que chez les autres, c'est propre, sauf qu'ils peuvent pas rediriger le son de leur smartphone vers la cafetière en bluetooth alors qu'avec Pulseaudio on peut (mais suivant une fonction pulse…)
Voilà une nouvelle solution qui va enfin tous nous mettre pas d'accord, parce qu'on n'arrivait plus à s'empoigner sur l'audio ces derniers temps.
Tout ça pour dire que je ne suis pas de niveau à commenter le projet, que je souhaite cependant un système de son simple et stable (aussi bien en fiab' que dans le temps!) pour Linux, et que j'espère que soit c'est le cas de KLANG, soit il disparaisse rapidement dans les abysses, parce que sinon y'a des schémas déjà un peu compliqués sur le son sous Linux qu'il va falloir complexifier encore un peu plus, alors que ce serait bien qu'on fasse plutôt le contraire.
Je ne partage pas les avis sur l'API d'OSS qui n'est plus utilisée sur Linux: je trouve moi que les développeurs ont une remarquable capacité d'adaptation aux nouvelles couches et surcouches audio, et une nouvelle passera en quelques mois sans problème (et puis on n'aura qu'à mettre une API de compatibilité Pulseaudio, qui aura elle-même son backend OSS, ça fera une nouvelle occasion de coder n'importe quoi en boucle…).
[^] # Re: Popcorn
Posté par karteum59 . Évalué à 3.
Bien d'accord avec toi !
Note que les deux posts suivants (qui datent un peu) ne sont pas inintéressants
http://insanecoding.blogspot.fr/2007/05/sorry-state-of-sound-in-linux.html
http://insanecoding.blogspot.fr/2009/06/state-of-sound-in-linux-not-so-sorry.html
Le résultat semble être plutôt un plaidoyer pour OSSv4 (apt-get install oss4-base sous Debian/Ubuntu). ça a (comme les autres systèmes) ses avantages et ses inconvénients, néanmoins j'avoue qu'à chaque fois que j'ai eu des soucis de son sous Linux avec ALSA/PA, ça en a résolu une bonne partie (et pas besoin d'un daemon pour que ça marche y compris lorsque plusieurs applications veulent sortir du son en même temps). Hormis les raisons historiques (licence->OSSv3 viré du noyau au profit d'ALSA), j'ignore s'il y a une raison technique valable pour que Linus refuse d'inclure OSSv4 de nos jours (mal écrit ? plus de code complexe dans le noyau -> probabilité de bugs plus importante ?). L'API d'OSS - aussi criticable soit-elle - semble être un dénominateur commun entre Linux et les *BSD (même si beaucoup de Linuxiens comme Lennard s'en fichent pas mal), et après tout personne n'oblige le développeur d'application à taper directement dans /dev/dsp, il suffit d'utiliser SDL/OpenAL/…
Cela dit, je me dis aussi qu'il n'est peut-être pas plus mal que le gros de la complexité reste en user-space (ce qui implique un daemon…) dès lors que les distros rendent ça simple et fiable avec une API stable dans le temps (OSSProxy ?). Je lis assez souvent que que PA est disons… criticable, et que jackd est excellent sauf pour la batterie de son smartphone / la consommation CPU / l'ergonomie, et du coup je me demande : est-ce que ce dernier est voué à rester ainsi par conception, ou est-ce qu'il est théoriquement concevable de le faire évoluer (avec un mode "à la PA") pour qu'il réponde aux besoins de M.-tout-le-monde et pas seulement des musiciens, de sorte qu'on ait un unique serveur jackd universel qui fasse consensus ? (oui, je sais… :). C'est une vraie question, je ne connais pas suffisamment jackd/ALSA/PA pour juger !
[^] # Re: Popcorn
Posté par gouttegd . Évalué à 4.
– la batterie de son smartphone : euh, je sais bien que le PC est mort et que l’avenir est aux smartphones et autres tablettes, mais je pense qu’on n’en est pas encore à faire de la MAO sur un smartphone…
– la consommation CPU : FUD? Jack has a very minimal CPU/memory footprint.
– l’ergonomie : euh, WTF ? Jack est un démon, depuis quand un démon doit-il être ergonomique ? Je veux bien qu’on critique l’interface de QJackctl à la rigueur, mais libre à tout le monde de développer un autre client graphique, il n’est pas nécessaire de tout remplacer pour ça.
C’est théoriquement concevable, oui, mais en pratiquement extrêmement peu probable, notamment parce que ce n’est tout simplement pas l’intention des développeurs de Jack. Oui, par conception, Jack ne cherche à répondre aux besoins que des MAOistes et pas de M.-tout-le-monde. Si M.-tout-le-monde veut un démon en espace utilisateur pour gérer le son, il y a PulseAudio. S’il n’aime pas PulseAudio, ben il fait comme moi quand je ne fais pas de MAO : j’utilise uniquement ALSA et tout marche très bien.
Rien ne permet de dire qu’un Jack adapté à M.-tout-le-monde ferait consensus. Personne ne se plaint de Jack parce qu’à part les musiciens (qui ne doivent pas représenter grand’monde), personne ne l’utilise. Si les distributions se mettaient à l’installer par défaut comme elles le font avec PulseAudio, je pense qu’on entendrait rapidement peu ou prou les mêmes critiques que l’on entend vis-à-vis de PulseAudio. Dans beaucoup de critiques de PA que j’ai pu lire, c’est le principe même d’un démon sonore en espace utilisateur qui est attaqué.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Popcorn
Posté par gouttegd . Évalué à 2.
Entre un mode « pour MAO » et un mode « desktop », tu veux dire ? En principe, c’est tout-à-fait faisable. À ma connaissance, rien ne s’oppose à ce que Jack (pour la MAO) et PulseAudio (pour l’utilisation de M.-tout-le-monde) soient installés simultanément, il devrait être envisageable de passer de l’un à l’autre en un clic sur un widget du bureau. Yapluka coder ledit widget, ou convaincre un développeur de le faire.
Autre possibilité, utiliser PulseAudio par défaut pour M.-tout-le-monde (c’est l’orientation prise par la plupart des distributions de toute façon, du moins il me semble), et configurer QJackctl pour désactiver PulseAudio au démarrage de Jack et le réactiver à l’arrêt de Jack. Il suffirait alors de lancer Jack pour passer en « mode MAO ». Ça a priori c’est déjà faisable avec ce que l’on a actuellement.
Désolé, là je ne vois pas vraiment ce que tu veux dire.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4. Dernière modification le 02 août 2012 à 22:09.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Popcorn
Posté par gouttegd . Évalué à 3.
Sous Linux, je pense que les cgroups sont une réponse à ce besoin, mais je reconnais qu’il y a deux problèmes :
– Il n’y a pas, à ma connaissance, d’interface user-friendly pour manipuler les cgroups (à moins que l’on ne considère que
echo $PID > /sys/fs/cgroup/audio/tasksest user-friendly, ce qui n’est vrai que pour certaines valeurs de user), la meilleure option à l’heure actuelle est d’utiliser cgrulesengd(8), qui ne se configure que par l’intermédiaire du fichier/etc/cgrules.conf. Rien n’empêche à priori de créer une interface facile d’utilisation, comme je disais plus haut, yapluka…– Il est délicat pour les développeurs de distributions de proposer une configuration par défaut, simplement parce que tous les utilisateurs n’ont pas forcément les mêmes besoins. Une configuration « générique » conçue pour satisfaire le plus de monde serait à mon avis assurée de ne satisfaire personne…
[^] # Re: Popcorn
Posté par Alex . Évalué à 2.
Il est délicat pour les développeurs de distributions de proposer une configuration par défaut, simplement parce que tous les utilisateurs n’ont pas forcément les mêmes besoins.
Pourquoi pas après tout, il n'y a pas si longtemps (et ça se fait peut être encore) SuSE proposait une configuration server, une desktop et une multimedia. De mémoire seul les noyaux changeaient.
De plus, je ne pense pas que cela soit si compliqué: après tout, quel que soit le profil utilisateur, si une application a des besoins "temps réel" , elle devrait être légèrement "prioritisé".
[^] # Re: Popcorn
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Logiquement, si le scheduler de tache est correct, il ne devrait pas y avoir de problème de trou dans le son. Cela a été la grande gueguerre entre le scheduler actuel et le BFS de Con colivas. ( http://en.wikipedia.org/wiki/Brain_Fuck_Scheduler )
Après les patchs low latency, d'il y a quelques années, Linux ne devrait pas avoir de trou dans l'écoute du son. Le problème concerne les drivers qui prennent le cpu trop longtemps. Il y a quelques années le driver NVIDIA pouvait prendre le bus PCI pendant 300ms. Difficile de faire du temps réel audio avec ce genre de latence maximum.
Il y a encore des problèmes avec les driver USB storage et plus généralement tout ce qui touche aux disques dures qui peuvent induire des latences non voulu. Il y a quelques temps, même un cat /dev/zero > /dev/null pouvait ralentir un système.
les cgroup permet de mieux isoler les types d'application entre elle, mais ce n'est pas super simple à utiliser.
"La première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Popcorn
Posté par lolop (site web personnel) . Évalué à 2.
Sous KDE il y a le mixeur qui fait ça bien (l'onglet flux de lecture liste les applis qui utilisent la carte son).
Et en plus il y a la gestion des multiples cartes son via Phonon par laquelle on peut spécifier, par type d'application (notifications, musique, vidéo, communication, accessibilité, jeux), quel périphérique utiliser.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -7. Dernière modification le 03 août 2012 à 09:56.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Popcorn
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 5.
Il ne liste que les applications qui jouent du son.
[^] # Re: Popcorn
Posté par zebra3 . Évalué à 7.
À quoi ça sert d'afficher les applications qui ne font pas de son dans le mixeur de son ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Popcorn
Posté par reno . Évalué à 3.
Pourquoi c'est modéré positivement ça??
Firefox peut beeper, jouer de la musique et même un beep c'est un son!
[^] # Re: Popcorn
Posté par zebra3 . Évalué à 2. Dernière modification le 03 août 2012 à 11:40.
Ah bon ?
Dans ce cas, il est affiché. C'est le cas sous GNOME : Epiphany n'apparait que lorsque je vais sur Youtube, pas le reste du temps, c'est logique.
Reste que si l'appli ne peut pas faire de son, ça ne sert à rien de l'afficher.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Popcorn
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
Si ton but est de mettre un mute sur une application qui envoie un son de temps en temps, ce comportement de la gestion du son est parfaitement insupportable.
"La première sécurité est la liberté"
[^] # Re: Popcorn
Posté par lolop (site web personnel) . Évalué à 4.
Sous KDE les applications qui peuvent utiliser le son pour des notifications ont une entrée dans la configuration du système, et pour chaque événement tu peux choisir la façon dont il doit être rapporté (bip, son, message, log, commande exécutée…).
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Popcorn
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 1.
Sauf que si tu veux temporairement désactivé les sons événements d'une apli c'est pas vraiment pratique de changer toutes les notifications…
[^] # Re: Popcorn
Posté par zebra3 . Évalué à 2.
Justement, dans le système de notifications tu peux les configurer une par une.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Popcorn
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
Oui, c'est bien le problème.
Use-case : je regarde un film, je veux désactiver les notifications audio de kopete mais pas celles de kmail. Avec ce que tu proposes, je dois donc désactiver les 5 notifications audio de kopete à la main, et les réactiver une fois le film fini -> pas vraiment pratique.
La configuration des notifications kde est hyper bien, mais seulement pour configurer le cas général. Quand tu veux temporairement désactiver des notifications c'est pas ce qu'il y a de plus pratique…
[^] # Re: Popcorn
Posté par Alex . Évalué à 2.
c'est un cas particulier
la question est de savoir s'il la majorité des utilisateurs en ont besoin
Ceci dit, ça serait bien dans l’esprit de kde d'offrir les 2 alternatives
[^] # Re: Popcorn
Posté par lolop (site web personnel) . Évalué à 5.
Si firefox utilise effectivement le son (ex. lancement d'une vidéo sur youtube), alors chez moi il apparaît sous le nom ALSA plug-in [plugin-container]: ALSA Playback. Tu peux alors changer le volume pour cette appli spécifique, ou carrément le couper.
Je t'accorde qu'il serait bien d'avoir quelque part une liste des applications susceptibles d'utiliser le son afin de pouvoir leur affecter un volume par défaut. Ceci dit, si ça doit intégrer toutes celles qui risquent de faire un "bip" d'alerte, ça va être lourdingue, il faudrais se limiter aux applis multimédias… où que les applis aient des tags indiquant comment elles travaillent (GUI / texte, avec son, avec vidéo, etc…).
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Popcorn
Posté par zebra3 . Évalué à 5.
Bienvenue en 2012, parce c'est déjà comme ça ! Je lance plusieurs applis audio et vidéo, et quand j'ouvre les paramètres du son de GNOME, je peux régler le volume de chaque appli.
Et pour KDE c'est pareil.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0. Dernière modification le 03 août 2012 à 10:43.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Popcorn
Posté par devnewton 🍺 (site web personnel) . Évalué à 0.
Un screenshot pour un problème audio? Il fait quel bruit ton Eclipse, il lit ton code source?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Popcorn
Posté par lolop (site web personnel) . Évalué à 2. Dernière modification le 03 août 2012 à 13:02.
Si tu listes toutes les applications qui génèrent des "bips" pour signaler des états, ça devient ingérable.
==> gestion des évènements par application dans la config KDE.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Popcorn
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Oui le son c'est dur à voir.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Popcorn
Posté par MTux . Évalué à 2.
Es-tu sûr que ces applis jouent des sons, je pense plutôt qu'elles envoient une notification à KDE, et que c'est lui qui joue un son.
[^] # Re: Popcorn
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 4.
Firefox qui joue du son, c'est via flash ou ?
Eclipse joue du son genre un flux continue, ou genre un son court sur des événements ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3. Dernière modification le 03 août 2012 à 11:03.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Popcorn
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 6.
Je suis parfaitement d'accord avec toi. Le système actuel ou tous les sons dus à des événements vont dans « event sounds » (je ne connais pas la traduction en français) ne permet pas une granularité assez fine. Je suppose bien sûr que puisque tu te plains tu as remplis un rapport de bogue.
Au passage, je suis curieux de savoir si Windows liste Avast (ou autre antivirus) dans les applications (et que donc, comme tu le sous-entend, il est possible de ne pas entendre les messages d'Avast).
Ça montre surtout que tu n'es absolument pas clair. Quand tu parles d'une appli qui joue du son, on comprend une appli qui joue du son, pas une appli qui va peut-être un jour jouer du son mais que pas en ce moment.
Ton screenshot ne montre rien du tout puisque tu ne donnes aucun détail sur ce que font les applications.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1. Dernière modification le 03 août 2012 à 12:39.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Popcorn
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 1.
S'il avait joué du son au moment de ton screenshot, il serait apparu dans la liste.
Tu coupes « event sounds », qui représente l'ensemble des sons liés aux événements.
Ta proposition n'est pas vraiment faisable, mais on peut imaginer que les applications préviennent pulseaudio qu'elles peuvent jouer des sons suite à des événements et que le mixer afficher un slider par appli qui s'est « enregistrée ».
Je te l'ai déjà dit, mais tu obtiens gratuitement un système complet, et tu te plains dans le vide au lieu de faire un rapport de bogue constructif. N'est-ce pas un peu exagéré ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -6. Dernière modification le 03 août 2012 à 13:40.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Popcorn
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 3.
Tu parles du temps passer à râler au lieu de faire progresser les choses ?
J'aimerais bien que tu me dises qui t'a fait des promesses.
Les développeurs ont un fonctionnement qui leur convient : ils désactivent tous les sons liés aux événements, ou bien aucun.
Pour les sons qui ne sont pas liés aux événements, comme un jeu, un lecteur multimédia, ou une appli fash qui rend fou, il y a possibilité de gérer les flux indépendamment.
Si tu avais cherché ne serait-ce qu'un peu, tu aurais découvert que les développeurs de pulseaudio sont ouverts aux changements et proposent de l'aide pour les patchs.
Quand on voit les fonctionnalités qu'on avait avant pulseaudio et après, ça progresse clairement dans le sens que tu veux (une granularité plus fine sur le contrôle des flux audio), même s'il y a encore des progrès à faire.
Quand à comparer avec Windows, de ce que j'ai vu, il y a aussi des défauts : pas possible de changer facilement une appli d'une carte son à l'autre, pas possible d'envoyer facilement un flux sur une carte son d'un autre ordi du réseau.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Popcorn
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 6.
Alors qu'il est bien connu que tous tous les utilisateurs veulent pouvoir désactiver les sons liés aux événementsd'une appli mais pas des autres (on parle bien des sons très cours lors d'un événement, hein, pas d'une appli qui joue du son en continu).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Popcorn
Posté par Xavier Teyssier (site web personnel) . Évalué à 8.
si un développeur n'est pas capable de voir que ce genre de fonctionnement pose problème, sérieusement je doute qu'il soit capable d'en faire quoi que ce soit.
User > Xate, tu peux aller récupérer mon fichier dans les sauvegardes ?
Xate > Oui, quel fichier ?
User > Celui que je viens d'effacer, évidemment !
Xate > Ah ! Oui ! Évidemment…
Rhâââ ! Fichus admin/développeur pas capable de deviner ce que veulent les utilisateurs ! Pour être admin ou développeur, faudrait imposer une épreuve de divination !
[^] # Re: Popcorn
Posté par bubar🦥 (Mastodon) . Évalué à 4. Dernière modification le 05 août 2012 à 09:22.
On a oublié de toucher quelques mots à propos d'un petit plugin en train de mourir depuis longtemps et pourtant toujours «si indispensable» : Flash.
Ce petit plugin est passé par :
_ pas d'autre son si flash utilisé, au début, souvent -> chiant
_ puis pas possible de faire fonctionner du son dans flash si un studio jack était lancé -> arrêt de tout son studio juste pour écouter du flash : chiant.
_ les devs de flash ont pris en charge pulseaudio sans balancer le support de alsa direct, et on publié un fameux dessin..
.
Bref, ce truc proprio si décrié mais tellement utilisé aurait pû faire le choix de passer par SDL, et hop, c'était réglé dans tout les cas de figure. Meuuuh non, le plugin a visiblement préféré ficher un peu la merde, tout du moins : montrer que "c'était le bordel"… c'est vrai, mouhai, ok… mais bon flash aurait pu utiliser SDL.
Si je cause de flash c'est pas vraiment au hasard dans la mesure où ton commentaire fait valoir "les cas d'utilisation" : ça semble assez flagrant que l'assertion tant répétée "tout les cas d'usages ne peuvent pas être pris en compte" est fausse, comme tu le 'sous-lignes', en premier lieu. Ce qui change ce sont les réglages et le "tuning" que va pouvoir demander tel usage, mais que le son ne fonctionne pas tout le temps dans tout les cas est assez… "ça la fout mal", oui. Mais surtout ces cas d'usages qui ne fonctionnent pas sont des situations souvent crées par de tout petits détails (flash qui ne donne pas envie d'utiliser autre chose que ce que lui voudrait décider, ce qui s'est ressenti au début de PA, qui avait bien compris l'importance de sa prise en charge).
Finalement ce sont vraiment de tout petits détails, des cas non pas d'un usage quotidien mais d'une pratique quotidienne… Flash qu'il n'est possible d'utiliser en même temps qu'un studio, PA même avec les dernières améliorations qui consomme du cpu d'une manière problématique pour l'autonomie juste pour mixer trois sources de michue, Jack qui ne permet pas de faire facilement des politiques de routages par défaut. Mais aussi : la diplomatie faisant que jack est "pro" alors que pa est "michu", bam un truc "en plus" au lieu d'être "à la place". Mais aussi : les couches d'abstraction "nécessaires" pour maintenir des bureaux avec du son sur d'autres unix.
Je ne sais pas ce que va devenir Klang, ni c'est "bien ou pas", mais dans tout les cas je le remercie de mettre les pieds dans le plat là où il faut : le noyau. Une modification, quelle qu'elle soit, serait l'assurance d'une évolution pérenne (et pour tous, android y compris), et permettrait aussi aux distributions "nous c'est linux" de virer les surcouches …
mes zéro virgule deux cents
[^] # Re: Popcorn
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Quand on voit l'énergie qu'il faut au monde libre (sandboxing dans les navigateurs, scripts d'installation pour aller chercher le binaire sur le site d'adobe) et les problèmes qu'il pose (son, consommation CPU, plantages) pour gérer les problèmes de flash, je ne sais pas s'il faut se réjouir de l'arrivée d'un autre petit logiciel privateur (steam)…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Popcorn
Posté par reno . Évalué à 5.
Hum, le sandboxing dans les navigateurs n'est pas spécifique à Flash, c'est juste un design de bon sens pour la majorité des plugins d'un navigateur: Firefox n'est pas un exemple à suivre au niveau design.
[^] # Re: Popcorn
Posté par spider-mario . Évalué à 1.
PulseAudio fournit lui-même un exécutable qui permet ça :
pasuspender.[^] # Re: Popcorn
Posté par karteum59 . Évalué à 2.
Ce n'était pas le sujet. Le sujet, c'était "one ring to rule them all" i.e. est-il possible d'avoir un unique daemon qui fédère les efforts de tout le monde plutôt qu'une fragmentation des efforts de développement ? Bref, est-il possible que jackd réponde aux besoins des utilisateurs "normaux" ?
Sauf qu'on a vu avant que
- pour beaucoup de gens, PA marche "en fonction pulse" (ah ben ça marche plus. Bizarre, ça marchait il y a 10 minutes…)
- ALSA ne mixe pas plusieurs sources (donc pour beaucoup de gens qui n'ont pas de mix hardware, cela signifie que seule une appli peut sortir du son à la fois)
Bref contrairement à ce que tu dis, pour beaucoup de gens, le problème n'est pas résolu (et après on se plaint que les gens achètent du Mac. J'entends même assez souvent des geeks me dire que "tu as les avantages de Linux, sauf que contrairement à Linux ça marche" [je précise qu'ayant eu pendant un temps un Mac au boulot, j'ai finalement laissé tomber et suis revenu à Linux pour mon plus grand bonheur, mais il y a une part de conviction et de sacerdoce…]).
Après, peut-être que l'idée d'utiliser jackd pour tout le monde est une mauvaise idée, et que PA bonifiera avec le temps. Je déplore juste de voir que les efforts sont dilués avec des bases de code distinctes et des APIs incompatibles.
Non, ce qui est critiqué, c'est le fait que ça ne marche pas !
[^] # Re: Popcorn
Posté par gouttegd . Évalué à 1.
Je pensais avoir répondu : à mon avis, non.
Ah, c’est donc pour ça qu’il s’appelle « PulseAudio » ! Blague à part, n’ayant jamais utilisé moi-même PulseAudio je lui accorde le bénéfice du doute en supposant qu’il fait correctement ce qu’il est censé faire. S’il ne le fait pas, il faut le corriger, mais ça n’invalide pas le principe.
Oui, et pour moi ça tombe bien parce que c’est exactement ce que je veux. Quand je ne fais pas de MAO et que je me comporte en « utilisateur normal » qui veut écouter de la musique ou regarder une vidéo, je ne veux pas qu’une autre application vienne injecter du son. Qu’ALSA ne le permette tout simplement pas est parfait pour moi, à la limite je dirais même « it’s not a bug, it’s a feature ». C’est pour ça que je n’ai jamais ressenti le besoin d’utiliser PulseAudio (ou n’importe lequel de ses prédécesseurs, comme arts ou esd).
J’en suis désolé. Mais si le problème n’est pas résolu parce que PulseAudio n’est pas au point, améliorer PulseAudio me semble une meilleure piste que de confier ses fonctions à Jack, et une bien meilleure piste qu’inventer un tout nouveau système sonore directement dans le noyau.
Et bien sûr, le projet KLANG va miraculeusement changer tout ça. Ou pas.
# The art of reinventing the wheel
Posté par gyom gyom . Évalué à 3.
Pourquoi réinventer un truc qui existe déjà, que les meilleurs codeurs du monde se sont pris la tête à créer, coder, tester, améliorer…
http://www.openbsd.org/cgi-bin/man.cgi?query=aucat&sektion=1
[^] # Re: The art of reinventing the wheel
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Tu saurais nous présenter ce projet un peu plus en détail, avantages, parti-pris, ambitions ?
J'avais déjà lu un peu dessus et ça m'intéresse beaucoup, au moins par curiosité, mais je ne trouve pas beaucoup à me mettre sous la dent ! Tu pourrais faire un journal dessus, ça peut intéresser beaucoup de monde ici (en réservant les trolls pour les commentaires ;-) ).
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: The art of reinventing the wheel
Posté par zul (site web personnel) . Évalué à 5.
En dehors du man associé qui m'a l'air plutôt bien fait, on peut trouver un papier présenté à AsianBSD sur les motivations / choix / limitations (http://www.openbsd.org/papers/asiabsdcon2010_sndio.pdf). Il y'a aussi les slides de la présentation (http://www.openbsd.org/papers/asiabsdcon2010_sndio_slides.pdf) et la vidéo associée (http://www.youtube.com/watch?v=Wcro3UliMZ4). Depuis le papier, il semble entre autre qu'ils aient implémenté la partie réseau.
# Hélas, ça ne va pas résoudre le problème, mais l'aggraver...
Posté par delio . Évalué à -5.
https://xkcd.com/927/
[^] # Re: Hélas, ça ne va pas résoudre le problème, mais l'aggraver...
Posté par Xavier Teyssier (site web personnel) . Évalué à 10.
Tu as sept jours, une heure et dix-huit minutes de retard…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.