Il y a près d'un mois, j'ai installé une Debian a des fins expérimentales. Dans ce journal, je vais vous détailler tout ce que j'ai pu tester dessus, en passant par KDE 4.3 (en installation full), GRUB 2, les outils de Debian et OSSv4.
C'est sur ce dernier point que je vais le plus m'attarder, car il est le plus intéressant.
Tout d'abord, ce n'est pas la première fois que j'installe Debian. C'est simplement la première fois que je l'installe pour réellement l'utiliser, et pas seulement pour avoir un support pour l'environnement de bureau Logram que je développe (pour voir comment il régi "sans filet"). J'ai donc installé tout le nécessaire.
Commencons par la fin d'un troll : Debian est à jour. Le 4 avril, j'ai installé Debian. À 18h précise et tapantes, KDE 4.3 sortait. Environ 30 minutes plus tard, les paquets i386 de KDE 4.3 entraient dans Sid. Il aura malheureusement avoir attendu le lendemain pour pouvoir les installer tous, en amd64.
Comme je pouvais m'y attendre, c'est stable et bien empaqueté. Debian est réputée pour cela, ça ne me surprend pas. Ce qui me surprend est la rapidité et la légèreté du machin. C'est la première fois que le déplacement d'une fenêtre, sans effets activés, est aussi fluide que si la fenêtre était du papier sur mon écran, c'est dire ! (bon troll quand-même : je viens d'Ubuntu)
J'installe donc kde-full, qui contient absolument tout ce qui est en rapport avec KDE (kdebase, kdelibs, kdeutils, kdeamdin, kdenetwork, kdeedu, kdegames, kdetoys, kdevelop, kdevplatform, kdesdk, etc). Pour tester au maximum le "code KDE", j'installe Amarok 2.1 et KOffice 2.0 (toujours depuis Sid).
Je teste, ça marche bien, mais je ne m'attarde pas trop. En effet, un but se cache en dessous de tous ces tests : fournir une base à la distribution Logram. Pour cela, je veux le meilleur, et je le teste.
Après KDE, je passe à ... OSS. Oui, vous avez bien lu, et non, je ne suis pas fous. En effet, OSS a la réputation d'un truc vieux et abandonné. Et même s'il commence à se séparer de cette réputation, il passe donc à "soft à la licence douteuse propriétarisée". Et pourtant, la licence de OSS est on ne peut plus claire, et au choix s'il vous plaît (GPL, LGPL et BSD, le tout gratuit bien entendu).
Après quelques recherches, j'arrive à trouver le lien de téléchargement. Je télécharge, choisis la version GPL (appropriée à Linux), et suis les instructions de compilation.
Une fois OSS installé, un petit redémarrage (après suppression de alsa, mais pas de libasound, on en aura besoin), puis je tape "osstest". Un son magnifique, cristallin jailli de mes haut-parleurs. Je ne savais même pas qu'ils en étaient capable ! Bref, essayé, c'est adopté.
Par chance, la majorité de mes applications marche avec OSS (Extreme tux racer, mplayer, etc). Il y en a néanmoins qui n'ont pas vraiment envie d'utiliser OSS. Heureusement, pour arranger ça, j'installe libasound (comme pour Alsa, mais sans Alsa), et place ceci dans /etc/asound.conf :
pcm.!default {
type oss
device /dev/dsp
}
ctl.!default {
type oss
device /dev/mixer
}
Pas besoin de redémarrer, toutes les applis ALSA fonctionnent, avec l'excellente qualité de son de cette version 4 de OSS.
Reste encore un problème : KDE utilise Solid, qui utilise HAL, qui est incompatible avec OSS. Résultat : pas de son dans KDE. Ce n'est pas un problème, je checkout le backend VLC pour Phonon (ici : svn://anonsvn.kde.org/home/kde/trunk/playground/multimedia/phonon-backends), compile, et installe.
Ensuite, System Settings»Multimédia»onglet Moteur, je met VLC tout en haut, puis retourne au premier onglet. Je n'ai plus qu'à choisir "oss" dans la liste, à démarrer Amarok, et à tester ... ça marche :) . Bon, le backend VLC n'est pas encore stable, il y a quelques imperfections (les mp3 sont gérés, mais pas les ogg, et le seek a un peu de mal), mais globalement, mon environnement est utilisable.
Pourquoi OSS me direz-vous ? Et bien, j'ai simplement suivi les conseils de ce blog, qui désignait OSS comme grand gagnant de la course au meilleur système audio. Il faut dire que OSS a tout pour lui :
- Mixage logiciel de haute qualité à base de nombres flottants, pour toutes les applis (alors que ALSA ne le fait que pour les applis ALSA)
- Bien plus léger, stable et rapide que PulseAudio
- Une API simplissime : sortir du son PCM 48khz dans /dev/dsp
- Mixage avancé (par entrée/sortie et par application, s'il vous plaît)
- Bon support matériel
- Excellente qualité de son
- Compatibilité irréprochable avec ALSA (puisqu'on utilise ALSA avec mon petit hack)
- Cross-plateforme : nos amis BSDiens peuvent aussi tester
C'est donc un sans faute. J'ai maintenant un système de son "à la Windows", qui juste-marche (fini les applis qui n'arrivent plus à avoir accès au son, les décalages, les plantages, etc).
Autre expérimentation sur ma Debian plus tellement toute fraîche : le démarrage. Plymouth, le boot graphique utilisé par Mandriva et par Fedora ne se trouve pas encore dans Debian. Dommage. Splashy plante royalement et fonctionne mal, dommage aussi.
Tant pis, pas de boot graphique. Je vais donc l'accélérer. Par chance, je vois que Debian n'est pas si à côté de ses pompes. Et oui, comme les autres distribs, Debian travaille à nous fournir un démarrage parallèle, rapide, et compatible 100% avec les anciens scripts.
Le secret est simple : un script /etc/rc.d/rc un peu modifié, un script qui pré-ordonne les fichiers, et quelques modifications. Il en résulte un dossier /etc/init.d tout à fait ordonné, avec les services pouvant démarrer en même temps commençant par le même numéro. Rc se charge ensuite de les charger en parallèle. La méthode est décrite ici, dans le passage sur insserv.
Le résultat est spectaculaire : avec MySQL, Apache, Exim, KDM, OSS et les services de base, mon démarrage prend 18 secondes, et Bootchart me montre que mon disque dur est pleinement utilisé, ainsi que le processeur. C'est vraiment foudroyant.
Encore une expérimentation : GRUB 2. D'ailleurs, Debian m'a proposé de l'installer, ce qui est une excellente chose. Je n'ai rien eu à faire. Il me semblerait qu'on soit bien parti pour avoir GRUB 2 dans Squeeze par défaut.
GRUB 2 apporte son lot de nouveautés et de perfection. Le fichier /boot/grub/grub.cfg (remplaçant du menu.lst) est sous forme de script, bien plus configurable (on peut mettre des if dedans, c'est dire). Il gère tout un tas de système de fichiers, le passage en mode graphique (on donne la résolution, il fait le reste, plus besoin de jouer avec des 0x31B et autres), et le KMS pour les noyaux Linux. C'est donc un succès.
Voilà, ce test était bien chargé. Ca m'a pris près d'un mois, mais je ne regrette rien. J'ai au final une distrib plus qu'alléchante, construite de mes petites mains :
- Linux 2.6.30-1
- KDE 4.3 au grand complet
- OSSv4 pour un son parfait qui juste-marche
- GRUB 2 pour un démarrage graphique et un framebuffer toujours à la définition maximale de mon écran (même quand je change d'écran)
- Un démarrage foudroyant en moins de 20 secondes
Le tout testé sur un petit PC dont la configuration est la suivante :
- Intel ATOM dual core à 1,6Ghz
- Un petit disque dur de 200 Gio (il est petit de taille, donc format "disque des gros iPod d'ancienne génération")
- Carte graphique Intel intégrée (une 945GM -_- , mais ça marche bien avec Debian, à condition de ne pas vouloir de 3D (même Extreme Tux Racer a du mal))
- 2Gio de RAM (ça marchait très bien avec 1Gio, oui oui, même KDE, mais j'en avais besoin de plus pour éviter de swapper quand je lance Konqueror+KDevelop+Amarok+Quassel+Kopete+Kmail+Kword+...)
- Connexion par ethernet
J'ai également installé Gnash, qui marche. Pour info, voici ce que me donne VRMS (Virtual Richard Stallman) :
$ vrms
No non-free or contrib packages installed on logram! rms would be proud.
C'est agréable d'avoir un système exclusivement et entièrement libre, n'est-ce pas ? (et avec accélération graphique, comme quoi on a bien évolué depuis les années 2000)
Bons tests, et à une prochaine fois (peut-être que Mandirva passera à la casserole, elle se trouve encore dans VirtualBox, mais plus pour longtemps. Je vous en direz des nouvelles)
# OSS, ou comment le bien devient mal.
Posté par Ph Husson (site web personnel) . Évalué à 7.
Déjà tu dis que toutes les applications ont un mixage grace à OSS... Bah non, c'est toutes les applications qui gèrent (in)directement OSS, les autres ont juste pas de son... Comme alsa, pulseaudio, et les autres en fait.
Ensuite que le mixage soit à base de flottants, j'en ai rien à faire (en fait a priori ils le font tous), et ne donne aucune information supplémentaire. Sinon ta "haute qualité" correspond à quoi ? Personnellement j'ai jamais senti de différence quelconque entre les différents mixer audios existants (pourtant j'ai une oreille relativement bonne). Pour la légereté par rapport à pulseaudio, c'est par rapport à quoi ? Si c'est dans le sens que pulseaudio est lourdingue à utiliser/installer, c'est uniquement un problème de distributions, sous mandriva par exemple ça marche plutôt bien. Si c'est niveau consommation mémoire, vu ta notion de "petit PC", ça changera pas grand chose. Il y a quand même le problème de CPU que pulseaudio se met à bouffer de temps à autre, mais bon plutôt un problème de jeunesse ça.
Pour l'API je pourrais pas te contredire, quelque soit le système audio, j'utilise le (faux)device /dev/dsp quand je veux l'utiliser directement, c'est sur que c'est nettement plus pratique.
Pour "l'excellente qualité de son", pareil que pour le mixage et la lourdeur, c'est basé sur quoi ?
Enfin, personnellement, le gros point noir d'OSS, c'est justement toutes les fonctionnalités que tu décris. Ces fonctionnalités n'ont rien à faire dans le noyau. Certes Linux n'a pas pour vocation à être un micro-noyau, mais tout ce qui peut se mettre relativement facilement du côté utilisateur, on le fait. Par exemple, jackd qui est considéré comme la réference pour le mixage (entre beaucoup autres.) de qualité sous linux est complètement en espace utilisateur, et utilise les drivers qui lui sont disponibles (ALSA ou OSS en fonction de l'OS/de la configuration)
PS:Bon ok je déborde un peu, mais faudra m'expliquer en quoi ta machine est un petit PC (sauf si c'est par la taille physique, mais à quoi ça sert de le préciser là ?).
[^] # Re: OSS, ou comment le bien devient mal.
Posté par Benjamin Poulain (site web personnel) . Évalué à 10.
Si tu as un mixeur sur la carte son de ton PC, ou que tu fais de l'embarqué et que le DSP s'occupe du mixage, tu veux que ce soit le matériel qui fasse le boulot. Pour ce faire, tu veux une partie du traitement du son dans le noyau.
Pour éviter les délais quand tu travailles avec du son (pour un instrument de musique par exemple), tu as intérêt à gérer le son dans le noyau.
Le lien habituel pour ceux qui veulent des explications sur comment fonctionne le son sous Linux et pourquoi OSS4 est une bonne solution (ce lien est d'ailleurs cité dans le journal):
http://insanecoding.blogspot.com/2009/06/state-of-sound-in-l(...)
[^] # Re: OSS, ou comment le bien devient mal.
Posté par Ph Husson (site web personnel) . Évalué à 3.
En ce qui concerne les délais, j'y ai pensé dans mon message, cf jackd (le temps réel sous linux, ça marche très bien quand on sait s'y prendre)
[^] # Re: OSS, ou comment le bien devient mal.
Posté par Benjamin Poulain (site web personnel) . Évalué à 6.
De plus, le noyau possède les informations nécessaires sur l'ordonnancement pour assurer les meilleurs délais pour l'audio. Ce genre de données ne sont pas disponible en user-space.
Bien sûr un on peut assumer que les ordinateurs sont devenu tellement puissant que ce genre de contraintes ne se pose pas, mais cette affirmation n'est pas vrai pour l'embarqué.
Un autre problème avec les serveurs de son est que ça ajoute des changement de contexte, ajoutant encore du délais si le processeur est chargé. Ces changements sont aussi plus coûteux pour les petits processeurs ARM.
[^] # Re: OSS, ou comment le bien devient mal.
Posté par geb . Évalué à 4.
On peut bricoller pour faire appli -> pulse audio -> jackd -> alsa/oss mais ça devient lourd.
J'aimerais vraiment prendre le temps de tester comme il faut OSS, qui , de ce que j'en entend poutre pas mal...
[^] # Re: OSS, ou comment le bien devient mal.
Posté par bubar🦥 (site web personnel) . Évalué à 3.
Les quelques cas ne supportant pas Jackd s'y sont mis (le meilleur exemple est Audacity, ouf. Mais aussi RecordMyDesktop). Quelques cas encore ne supportent vraiment pas Jackd, parcequ' ils sont liées au choix du bureau (esd/arts/pulse/phonon) et ceux sont qui "mixent" ou se charge du "routage vers". Enfin il me semble avoir rencontré quelques cas qui ne supportent pas Jackd effectivement, ni le "routage au niveau du bureau", je ne sais pas ce qu' ils deviennent.
Les développeurs LAD (linux audio developpers) font énormément d' efforts pour supporter le bronx du son sous linux. Les applications dites "professionnelles" se contentent de supporter Jack et la driver-family (oss / alsa) direct et rien d' autre. C' est déjà bien :) Les lecteurs (et ou monteurs) supportent quant à eux bien souvent une multitude de possibilités : drivers-family oss/alsa direct, et jackd, et arts et esd et pulse et et et ...)
Merci à eux. Et gageons qu' une éventuelle amélioration de tout ça (fusion jackd / alsa ? que sais je ?) leur permette d' être moins embéter. Et nous, utilisateurs, d' avoir une meilleure qualité par défaut sans trifouiller dans des docs "proaudio".
[^] # Re: OSS, ou comment le bien devient mal.
Posté par IsNotGood . Évalué à 1.
???
Ce n'est pas un argument valable. Le boulot du noyau est aussi d'ordonnancer les l'applis et le faire bien.
Et pourquoi pas mettre les lecteurs vidéos voire le serveur X11 dans le noyau tant qu'on y est ?
> Un autre problème avec les serveurs de son est que ça ajoute des changement de contexte, ajoutant encore du délais si le processeur est chargé.
Je ne vois pas pourquoi.
Sans serveur de son : 3 applis qui envoient du son, 3 applis qui demande des changements de contexte obligatoirement.
Avec serveur de son (en user space) : ces 5 applis seront peut-être (en fait probablement) des changements de contexte (l'écriture en IPC ne demande pas de changement de contexte) mais il n'y a pas de raison qu'il y en est plus.
Au final, pas facile à dire quelle configuration fera le plus de changement de contexte.
[^] # Re: OSS, ou comment le bien devient mal.
Posté par pasBill pasGates . Évalué à 3.
Euuh... Tu as vu ou qu'il peut y avoir des IPC sans context-switch ?
Les IPC coutent un context-switch a chaque fois, c'est inevitable.
Quand au probleme kernel<->serveur de son c'est assez simple :
Chaque app doit envoyer le son au serveur (1 IPC pour envoyer+1 IPC pour le serveur de son pour lire) qui lui doit l'envoyer au kernel (1 IPC)
Avec le mixer dans le kernel, l'app l'envoie directement au kernel (1 IPC)
Sachant qu'il y a rarement plus d'un ou deux softs faisant du son en meme temps, ca fait en comparaison :
pour 2 softs emettant du son :
user-space : 2*2+1 = 5
kernel : 2
pour 1 soft emettant du son :
user-space : 2+1 =3
kernel : 1
Bref, une sacree reduction...
[^] # Re: OSS, ou comment le bien devient mal.
Posté par Ph Husson (site web personnel) . Évalué à 2.
Parce que une architecture à base d'IPC est plus efficace sur du multicoeur en fait, alors que, si je ne me gourre pas (si quelqu'un sait que c'est faux qu'il le dise.), le thread noyau associé à un thread processeur tournent sur le même processeur, donc commutations de ring et compagnie, alors qu'avec de la mémoire partagée, on passe le noyau juste pour accéder au périph.
[^] # Re: OSS, ou comment le bien devient mal.
Posté par pasBill pasGates . Évalué à 2.
J'ai comment dire rien compris a ton explication, c'est quoi l'avantage du multi-coeur pour les IPC ?
[^] # Re: OSS, ou comment le bien devient mal.
Posté par IsNotGood . Évalué à 3.
Les IPC, du moins la mémoire partagée, ne demande pas de context-switch.
Il ne faut pas oublier que les thread demandent des context-switch (sauf si multi-cpu).
Les applis sons vont "plus vite que la musique" et donc passe en sommeil. C'est systématiquement un context switch. Ce "problème", tu l'as avec un serveur de son en userland ou en noyau.
Si lors de l'écriture dans le serveur de son au niveau noyau la carte son n'est pas disponible, c'est aussi un context switch.
Bref, ça change pratiquement rien.
[^] # Re: OSS, ou comment le bien devient mal.
Posté par pasBill pasGates . Évalué à 1.
Il ne faut pas oublier que les thread demandent des context-switch (sauf si multi-cpu).
La memoire partagee oui, le probleme est que tres peu de softs utilisent cela comme methode d'IPC, car c'est un sacre merdier de synchroniser la chose, surtout quand t'as plusieurs parties et pas que 2.
Les applis sons vont "plus vite que la musique" et donc passe en sommeil. C'est systématiquement un context switch. Ce "problème", tu l'as avec un serveur de son en userland ou en noyau.
Si l'appli fait que du son oui, maintenant tu prends un truc genre Flash sur un netbook, ca devient plus serre...
Si lors de l'écriture dans le serveur de son au niveau noyau la carte son n'est pas disponible, c'est aussi un context switch.
Bref, ça change pratiquement rien.
Euh si, il y a des buffers
Bref, ça change pratiquement rien.
Au contraire, ca change pas mal. C'est certainement pas la seule chose qui compte, mais ca a un impact non negligeable.
[^] # Re: OSS, ou comment le bien devient mal.
Posté par lolop (site web personnel) . Évalué à 1.
http://colin.guthr.ie/2009/08/sound-on-linux-anti-fud-calm-c(...)
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: OSS, ou comment le bien devient mal.
Posté par Aldoo . Évalué à 7.
C'est bien gentil, oui, sur le papier, PulseAudio est idéal. En pratique les performances sont assez misérables (à cause de mauvais drivers ALSA ? Autre raison ?).
L'impression que donne PulseAudio, pour moi, c'est se dialogue:
L'audio de base avec simple mixage logiciel est pourrie sous Linux ?
Ah mais c'est parce que ce qu'il vous faut c'est un système audio moderne, avec la transparence réseau, le glitch free, la machine à café etc...
... bref, une réponse à côté de la plaque.
Pourquoi ne pas commencer plutôt par améliorer les fonctionnalités de base ?
[^] # Re: OSS, ou comment le bien devient mal.
Posté par Aldoo . Évalué à 2.
C'est juste que dans l'état courant des choses, l'impression est bof bof.
Espérons que tout ça s'arrange vite.
[^] # Re: OSS, ou comment le bien devient mal.
Posté par lolop (site web personnel) . Évalué à 1.
AMA, il y a des moments où il te faut revoir l'architecture pour pouvoir rendre certains services, j'ai l'impression que c'est ce qu'ils essaient de faire avec PulseAudio. Et y'a encore du boulot...
C'est sûr que ça fait "une couche de plus" (il se base sur OSS/ALSA pour les accès matériel). Mais pour les développeurs ça fait une API pour pas mal de plateformes.
http://rudd-o.com/en/linux-and-free-software/how-pulseaudio-(...)
http://www.pulseaudio.org/wiki/AboutPulseAudio
Q? Pour quelle raison les différentes distributions l'ont-elles intégré aussi rapidement ?
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: OSS, ou comment le bien devient mal.
Posté par claudex . Évalué à 6.
Parce que Fedora (qui recherche plus l'intégration de nouvelles fonctionnalités que les autres) l'a fait et que les autres ont eu l'impression de se faire distancer par un truc révolutionnaire. Pulseaudio est un truc révolutionnaire mais pas fini. Et elles ont oublié le dernier détail.
« 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: OSS, ou comment le bien devient mal.
Posté par gnumdk (site web personnel) . Évalué à 3.
Si tu gardes pulseaudio, t'as des bugs sonores en permanences et si tu le vire, t'as plus de mixer dans le panel...
Resultat, je l'ai mise en place chez un ami et je me tate à mettre kmix :-/
[^] # Re: OSS, ou comment le bien devient mal.
Posté par boulde . Évalué à 2.
[^] # Re: OSS, ou comment le bien devient mal.
Posté par IsNotGood . Évalué à 1.
Des faits svp ?
Personne ne compare à algo de mixage équivalent. Par défaut PA prend un bon algo de mixage.
Combien consomme OSS pour le mixage et avec quel algo ?
On ne sait pas, c'est dans le noyau.
> Pourquoi ne pas commencer plutôt par améliorer les fonctionnalités de base ?
C-à-d ?
Pas de mixage, pas de support de périphérique branché à chaud (ce ne sait pas faire OSS), pas de redirection de son, pas de "switch user", etc.
Bref, améliorer ce que faisait déjà Linux il y a plus de 10 ans. Et pour quoi ? Pour gagner 0,001 % de cpu ? La grande affaire.
Les cartes sons vont de moins en moins avoir de mixeur intégré (sauf les très chères).
Je donne juste un petit exemple. J'ai un casque audio USB (avec micro). Avec PulseAudio (et alsa), je le branche à mon PC et basta tout marche. Je peux rediriger le son des enceintes vers le casque, le micro marche, etc.
Est-ce que OSS fait ça ? Pas sûr. Et pourtant c'est une fonctionnalité évidante à avoir. Ce genre de truc marche nickel sous Windows depuis des années, afin avec PulseAudio ça marche aussi sous Linux.
[^] # Re: OSS, ou comment le bien devient mal.
Posté par Aldoo . Évalué à 5.
Parce que l'algo de mixage d'ALSA ou d'OSS était mauvais ?
Pour moi ces algos ont une qualité suffisante pour la vie de tous les jours et ne font pas ramer ma machine, c'est tout ce que je demande.
Pulseaudio *fait* ramer la machine.
Pas de mixage,
Si, le mixage fait pour moi partie des fonctionnalités de base.
Et ce qu'il y a à améliorer, ce n'est pas les perfs, qui étaient déjà correctes en général, mais la compatibilité des applis.
C'était bien beau d'avoir Dmix si les trois quarts (certes un peu exagéré ;-) ) des applis se rétamaient dès que Dmix était impliqué.
Voilà après le branchement des périphs à chaud, toussa, je dis pas, ça peut être utile. Mais bon, Pulseaudio avait un peu été présenté comme le messie de l'audio, le the One Sound System to Rule Them All... alors qu'en fait il s'agissait surtout de nouvelles fonctionnalités (et pire, le mixage de base devenait du coup moins efficace qu'avec l'existant).
Donc forcément, il y a eu des déçus, et ce n'est pas étonnant que PA ait plutôt mauvaise presse aujourd'hui.
[^] # Re: OSS, ou comment le bien devient mal.
Posté par IsNotGood . Évalué à 2.
Il y a aussi des algo "pourris" avec PA, tu peux les selectionner pour gagner en cpu.
En passant, combien consomme OSS pour mixer et avec quel algo ?
On ne sait toujours pas...
le the One Sound System to Rule Them All...
PA n'a jamais été présenté comme ça. Il demande Alsa et "pousse alsa dans ses limites". La majorité des problèmes avec PA sont avec .... Alsa. Mais ça se corrige.
PA n'a jamais non plus prétendu remplacé jack pas exemple. Idem, PA ne remplace pas gstreamer. Il ne fait que serveur de son.
et pire, le mixage de base devenait du coup moins efficace qu'avec l'existant
Tu peux argumenter ?
PA est pire que esd ? que arts ? que dmix ?
En passant, dmix était un mixer en userland (comme PA).
ce n'est pas étonnant que PA ait plutôt mauvaise presse aujourd'hui.
PA a mauvaise presse pour quelqu'un.
PA est maintenant par défaut dans pratiquement toutes les distributions et la tendance ne va pas s'inverser.
OSS, du moins son service de serveur son, n'est pas une solution à long terme. À peine sorti et déjà sans avenir.
[^] # Re: OSS, ou comment le bien devient mal.
Posté par Aldoo . Évalué à 2.
Je n'ai pas de données chiffrées, seulement un constat personnel (mais très net... je suis convaincu que ce n'est pas que du ressenti !).
Les mêmes applis vont pédaler dans la semoule quand PA est utilisé alors que tout marche bien avec ALSA ou OSS seuls. Qui plus est la latence avec PA est dans ces cas-là de l'ordre de la demi seconde, et le son a souvent tendance à se dégrader.
Avec OSS, il n'y a aucun de ces problèmes: latence insensible (ça doit vouloir dire moins de 100ms... je ne faisais pas d'audio pro, mais dans ce cas je lancerais jackd et ferais en sorte d'être sous les 10-20ms), fluidité des applis et pas de dégradation.
Avec ALSA Dmix, il pouvait arriver une certaine dégradation du son perceptible en cas de surcharge.
Je ne sais pas à quoi cela est dû, peut-être qu'en effet OSS utilise par défaut des algos qui privilégient la performance avant la qualité (qui pourtant est suffisante pour moi... ). Sinon je suis intéressé pour jouer avec les paramètres de PA et choisir un autre algo de mixage... je vais jeter un œil.
Esd et de artsd, je n'en parle même pas... dans mes souvenirs artsd était bien pire que PA... et esd, j'ai assez peu pratiqué.
Bon tout cela étant dit, je pense que je suis d'accord que l'avenir c'est maintenant ALSA+PA. N'empêche que les plâtres sont loin d'être essuyés !
[^] # Re: OSS, ou comment le bien devient mal.
Posté par Patrick Lamaizière (site web personnel) . Évalué à 1.
On ne sait toujours pas
Rapide essai sous FreeBSD à la louche (avec KDE et tout le toutim)
Matériel : un macbook pro, son HDA
CPU Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz
J'ai 16 'vchans' ie des canaux audio virtuels qui sont mixés.
16 instances de mpg123 qui jouent le même morceau.
- avec la qualité du feeder max (voir http://people.freebsd.org/~ariff/SOUND_4.TXT.html hw.snd.feeder_rate_quality=4)
CPU: 4.9% user, 0.0% nice, 4.5% system, 41.3% interrupt, 49.3% idle
- avec la qualité du feeder min (hw.snd.feeder_rate_quality=0)
CPU: 4.5% user, 0.0% nice, 0.9% system, 1.3% interrupt, 93.3% idle
Même chose, mais pour un seul morceau à la foi
- avec la qualité du feeder max
CPU: 1.3% user, 0.0% nice, 6.0% system, 2.8% interrupt, 89.8% idle
- qualité min:
CPU: 0.6% user, 0.0% nice, 0.6% system, 1.1% interrupt, 97.7% idle
Je ne suis pas expert en son, mais ce qui apparaît c'est que c'est plutôt la qualité du feeder qui influe plutôt que le mixage. Intéressant j'ai mis la qualité au max alors que j'entend pas de différence, je vais la réduire.
L'algo utilisé pour le feeder est décrit dans le lien plus haut (j'ai pas tout compris...)
Pour finir je n'ai pas pulseaudio alors je ne peux pas comparer.
les pixels au peuple !
[^] # Re: OSS, ou comment le bien devient mal.
Posté par Patrick Lamaizière (site web personnel) . Évalué à 1.
J'ai essayé avec jackd mais le son lague avec 16 mixages et ça a l'air bien bogué ici (plein de zombies...).
Avec pulseaudio, ça tient la route avec 16 mixages et même sans utiliser la prioritée temps réel (resample-method = src-sinc-best-quality)
CPU: 10.5% user, 0.0% nice, 9.0% system, 2.4% interrupt, 78.0% idle
les pixels au peuple !
[^] # Re: OSS, ou comment le bien devient mal.
Posté par Moonz . Évalué à 10.
Si. C’est bel et bien au noyau que revient la tâche de gérer les accès concurrents à une ressource matérielle unique, c’est même une des caractéristiques principales d’un noyau.
[^] # Re: OSS, ou comment le bien devient mal.
Posté par Troy McClure (site web personnel) . Évalué à 1.
[^] # Re: OSS, ou comment le bien devient mal.
Posté par totof2000 . Évalué à 5.
Linux côté audio ça devient complêtement pourri. On est passé d'un truc simple comme OSS à une usine à gaz style Alsa, avec au dessus les couches gérées par les divers desktops, plus une autre couche chargée d'unifier tout ça, et après on se demande pourquoi un MAC est généralement utilisé pour la MAO. C'est un peu comme l'accumulation des couches avec les services web Java et le XML.
Si on laisse le soft faire le mixage, et qu'en plus il doit gérer les flux vidéo ou ce genre de chose ..... on va à la catastrophe. Et vous vous étonnez que les jeux ne soient pas portés sous Linux ???? En lisant ça, je ne m'étonne plus de rien.
[^] # Re: OSS, ou comment le bien devient mal.
Posté par Octabrain . Évalué à 4.
[^] # Re: OSS, ou comment le bien devient mal.
Posté par Frédéric COIFFIER . Évalué à 2.
http://blogs.adobe.com/penguin.swf/2007/05/welcome_to_the_ju(...)
[^] # Re: OSS, ou comment le bien devient mal.
Posté par Troy McClure (site web personnel) . Évalué à 5.
T'es au courant pour macos ? il mixe en soft, le demon s'appelle coreaudiod.
Que ça soit fait dans le kernel ou non est une décision qui regarde les dev du kernel. Et pour linux ils ont clairement choisi de ne mettre que le strict minimum dans le noyau, c'est pour ça que OSS n'a *aucune* chance de jamais revenir dans linux. Perso je trouve pas ça idiot, du code de mixage, de reechantillonnage, avec accessoirement des fonctionnalités de type plugin, c'est quand même bien même bien mieux en userspace que dans le noyau. Donc c'est jackd ou pulseaudio .
[^] # Re: OSS, ou comment le bien devient mal.
Posté par lolop (site web personnel) . Évalué à 3.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: OSS, ou comment le bien devient mal.
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Moi, je l'ai vu passer d'un truc où je ne pouvais avoir qu'un son à la fois comme OSS, à un truc où je peux en jouer plusieurs comme ALSA, puis finalement à un truc où on peut router les sons comme PulseAudio.
Si on laisse le soft faire le mixage
Tu en connais, des cartes son qui intègrent un mixeur matériel ? Moi pas.
[^] # Re: OSS, ou comment le bien devient mal.
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Et pourquoi pas un séquenceur MIDI matériel, aussi. Ça aussi, c'est du passé, qu'on le veuille ou non.
[^] # Re: OSS, ou comment le bien devient mal.
Posté par totof2000 . Évalué à 3.
[^] # Re: OSS, ou comment le bien devient mal.
Posté par Prosper . Évalué à 4.
Ma vieille soundblaster live permet de faire du mixage materiel depuis des années en oss ( en alsa aussi j'imagine ) , et si je ne me trompe pas ca doit taper dans les 32 canaux max , j'ose croire que les cartes suivantes permettent la même chose .
[^] # Re: OSS, ou comment le bien devient mal.
Posté par grid . Évalué à 4.
[^] # Re: OSS, ou comment le bien devient mal.
Posté par gnumdk (site web personnel) . Évalué à 4.
Maintenant, j'ai un chipset Intel (et plus de port PCI pour ma sblive) et figure toi qui c'est ALSA qui se charge de tout et que ca fonctionne très bien.
J'ai essayé PulseAudio, mais dès que la machine est un tout petit peu chargée, ça par en vrille...
Bref, vive Alsa
[^] # Re: OSS, ou comment le bien devient mal.
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: OSS, ou comment le bien devient mal.
Posté par Ph Husson (site web personnel) . Évalué à 2.
[^] # Re: OSS, ou comment le bien devient mal.
Posté par bubar🦥 (site web personnel) . Évalué à 3.
Alsa n' est pas sorti du chapeau juste pour enquiquiner les gens. Et certaines entreprises payent encore cher des drivers OSS pour la garantie RT en embarqué (oui!)
La jonction Jackd avec Alsa serait idéale.
ps : OSS a eu tellement de noms différents que je me demande de mémoire si c' est OSS qu' il faut encore utiliser aujourdhui ?? oui parceque c' est noté comme ça dans le noyau. point, après tout.
# ATOM ou AMD64?
Posté par NickNolte . Évalué à 6.
Sinon, dommage que ton journal sent trop le fanatisme.
Alalala, la fougue du jeune linuxien prêt à tous les superlatifs pour se convaincre que le temps passé à se crépigner le chignon avec ces histoires de "serveurs son" n'est pas perdu. :)
OSS étant complètement dans le noyau... non merci!
[^] # Re: ATOM ou AMD64?
Posté par steckdenis (site web personnel) . Évalué à 6.
Jeune jeune, peut-être, ça ne fait qu'un an et demi :-° (et je le regrette de temps en temps, de ne pas avoir connu KDE 2, les noyaux 2.4 et 2.2, et d'autres choses un peu plus vieillottes).
Et puis, côté temps perdu, ça m'a pris 2 heures à tout casser pour que ça marche bien, et ça marche encore toujours bien (et avant, j'avais ALSA, qui juste-marche aussi, mais j'avais envie de tester).
# GRUB 2, menu, if
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
Vous pensiez à faire un test sur le processeur pour voir s'il est en 64 bits ? C'est possible. Générer un menu selon le résultat ? Ça, ça ne l'est pas. Charger un fichier de configuration donné en fonction du résultat ? Ça, c'est bon, ça marche.
# Nostalgie...
Posté par Vlobulle . Évalué à 9.
Désolé pour les 24 heures d'avance.
[^] # Re: Nostalgie...
Posté par claudex . Évalué à 5.
« 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: Nostalgie...
Posté par Maclag . Évalué à 9.
Il parle de cette époque magnifique ou l'ordinateur était fait pour tout le monde... à condition que tu saches que ta carte son utilise l'IRQ7, et que tu comprennes comment changer la répartition de la mémoire au-delà des 640ko-de-mémoire-suffisants-pour-tout-le-monde entre paginée, étendue, etc., et ce différemment pour chaque application un peu lourde bien entedu.
C'est l'époque où on trouvait que quelques centaines de Mo, ça fait beaucoup, et on parlait du disque dur!
C'est l'époque où les Pentiums ne savaient pas compter!
Aaaaaah! QU'EST-CE QU'ON SE FAIT VIEUX A PARLER DU "BON VIEUX TEMPS"!
# OSS c'est bien MAIS...
Posté par ackernul . Évalué à 2.
Le gros problème c'est pour les carte HDA intel il détecte mal le passage sur prise jack, il ne coupe pas le son des HP, il faut le faire à la main :/
À par ça il n'y a pas de raison de proféré Alsa et pulse audio (si on n'utilise pas les fonctionnalité réseau).
[^] # Re: OSS c'est bien MAIS...
Posté par Janfi . Évalué à 10.
C'est vrai, qu'est-ce que je m'ennuierai sans PulseAudio !!
[^] # Re: OSS c'est bien MAIS...
Posté par Patrick Lamaizière (site web personnel) . Évalué à 2.
Si j'ai bien compris cela peut-être fait soit par le matériel directement ou alors le driver doit le faire. Sous FreeBSD j'ai du poser des quirks pour que ça fonctionne et j'en ai chié. Dans linux tu as aussi des quirks mais comme il y a plus de monde y'a plus de matériels déjà renseignés.
Mais où sont les bonnes vieilles SoundBlaster 16 d'antan ?
les pixels au peuple !
[^] # Re: OSS c'est bien MAIS...
Posté par bubar🦥 (site web personnel) . Évalué à 2.
OSS (semble, j' emploi semble, moi) présente un fonctionnement hors d' age. Pas assez de fonctions en espace utilisateur, trop de choses dans le kernel-land. Je suis très loin d' être spécialiste, mais je sais pkoi ça me semble logique... bon bref, mieux vaut lire des posts de Ph Husson et d' autres, hein :)
Message pour Tanguy Ortolo :
tu es passé de oss à alsa/dmix directement alors :) parcequ' avant dmix, le mixage logiciel n' était pas possible dans alsa, hein ;) d' ailleurs l' architecture de alsa ne semble pas le vouloir, d' où l' ajout de cette couche dmix pour les cartes n' ayant pas de mixer matériels (devenues une quasi norme grand public aujourdhui)
Voici mon impression :
le développement de pulseaudio a été très "user-oriented" en prenant d' abord en compte les "users-features" (Flash, Volume centralisé à la mode, bluetooth sur la roadmap, réseau).
Mais le "core" à besoin de (....), au mieux il est qualifié d' erreur de jeunesse, pour sa propention légendaire à manger les cpu tout crus pour ne fait que 2 mixages... au pire il fout en l' air tout le travail fait au dessus en rendant désagréable l' utilisation.
Jackd a été développé pour répondre à un besoin, un seul. Cette base saine et éprouvée immédiatement ont fait qu' il a été adopté par de très nombreux développeurs pour leurs applis. Aujourdhui le développement de Jackd se tourne vers l' utilisateurs : prise en charge du réseau (jack_lan ! l' essayer c' est l' adopter lui aussi !).
Mais il lui manque du travail d' intégration pour que les utilisateurs aient la vie simple (exemple : je lance une appli d' enregistrement, automatiquement les flux basculent sur elle, et elle a sa sortie sur le 'system'. ). Aujourdhui ce sont les développeurs de chaque applis qui doivent se taper ce boulot, alors que peut être ça serait à un soft de bureau de faire ça, cette facilité. ? Phonon est Génial pour ça, d' ailleurs...
mes 2 cents.
[^] # Re: OSS c'est bien MAIS...
Posté par bubar🦥 (site web personnel) . Évalué à 2.
Pour moi l' idéal serait de remplacer dmix par jackd (du moins, que jackd se rapproche de alsa) ainsi les notions de routage serait assurer par un système (très) viable, existant, résistant et capable de supporter des latences de fou.
Ce qui n' enlève pas du tout PulseAudio, qui pourrait être de plus haut niveau, et s' occuper des politiques à appliquer ainsi que des facilités pour l' utilisateur. Pour l' instant mon expérience fait que j' ai choisi : alsa-jackd-phonon. mais j' ai rien contre alsa-jackd-pulse, simplement je trouve qu' il y en a encore un (voir deux ?) de trop.
Mais je suis tout ouĩe...
[^] # Re: OSS c'est bien MAIS...
Posté par bubar🦥 (site web personnel) . Évalué à 3.
purée ce bronx :))
[^] # Re: OSS c'est bien MAIS...
Posté par grid . Évalué à 4.
# Alsa
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 7.
T'inquiète pas, j'ai jamais réussi à faire fonctionner Advanced LINUX Sound Architecture sous BSD de toute façon…
# la fin d'un troll ou le début d'un autre ?
Posté par B16F4RV4RD1N . Évalué à 6.
oui, la semaine de sa sortie. Ensuite quand c'est gelé... brrr tu peux attendre parfois 2 ou 3 mois avant d'avoir certains trucs à jour. Mais si tu n'utilises pas gnome, cela limite les risques.
Ce qui me surprend est la rapidité et la légèreté du machin.
n'utilise pas Archlinux alors, sinon tu vas t'envoler de ton siège ;)
je passe à ... OSS. Oui, vous avez bien lu, et non, je ne suis pas fous.
non, tu n'es pas fou bien sûr, OSS est le bon choix, mais c'est dommage qu'il ne soit pas supporté par plus de projets qui font du Alsa-seulement. Notamment les applications musicales. J'avais installé OSS, c'était super, par contre pour faire fonctionner mon clavier avec un adaptateur usb et rosegarden, j'ai dû revenir à Alsa :(
Sur l'ordinateur à mon boulot, j'ai pu garder OSS et j'en suis très content.
Après quelques recherches, j'arrive à trouver le lien de téléchargement. Je télécharge, choisis la version GPL (appropriée à Linux), et suis les instructions de compilation.
C'est pas si à jour et convivial que cela Debian alors... Avec d'autres distributions, oss est dans les dépôts officiels et c'est installable en une seule commande...
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: la fin d'un troll ou le début d'un autre ?
Posté par steckdenis (site web personnel) . Évalué à 2.
Effectivement, c'est là un problème de Debian. J'ai cru lire à un moment que OSSv4 se trouvait dans les dépôts, mais comme Debian est très chipoteur sur les licences, dès que le troll de "propriétarisation" a pointé le bout de son nez, hop, plus de OSS chez Debian.
Et puis, c'est tellement bien expliqué, et tellement simple :
tar -xf archive
cd archive
./configure # qui ne vient pas des autotools d'ailleurs, c'est du fait-main
make
sudo make install
sudo make modules
Et voilà.
[^] # Re: la fin d'un troll ou le début d'un autre ?
Posté par Christophe Roland (site web personnel) . Évalué à 1.
[^] # Re: la fin d'un troll ou le début d'un autre ?
Posté par asteroid . Évalué à 4.
[^] # Re: la fin d'un troll ou le début d'un autre ?
Posté par chimrod (site web personnel) . Évalué à 2.
# make install
par
# checkinstall
et le tour est joué !
[^] # Re: la fin d'un troll ou le début d'un autre ?
Posté par steckdenis (site web personnel) . Évalué à 5.
make debEt oui, qualité OSS : il génère des paquets .deb tout seul (et c'est propre, on sait désinstaller, etc).
# pc libre ?
Posté par briaeros007 . Évalué à -4.
Je trouve pas que c'est vraiment dans l'idéologie du libre ça mais bon...
[^] # Re: pc libre ?
Posté par briaeros007 . Évalué à 2.
[^] # Re: pc libre ?
Posté par steckdenis (site web personnel) . Évalué à 5.
Je veux du Linux, je vais au magasin, on me force à acheter du Windows, je fais plein de démarches, je perds de l'argent, j'installe Linux.
Différent non ?
Et puis, Intel, lui, fourni ses spécifications et est doté d'un pilote libre de grande qualité (même si on en a bavé, mais le 2.8 est extra).
[^] # Re: pc libre ?
Posté par briaeros007 . Évalué à 3.
Non.
Si tu vas au magasin acheter une bécane, c'est soit intel only, soit 80% de la gamme intel, et c'est souvent le bas de gamme en AMD.
Si tu parles de l'assembleur ... ben c'est le même problème que pour windows.
A ton avis, pourquoi ils ont été condamné ? Parce que ils ont respecté la loi et que personne a été blousé dans cette affaire ?
Bref, c'est bien ce que je dis intel, faut surtout pas dire qu'ils font des trucs mal, même si ils en font.
Après tout ils ont sortis des trucs libre, donc c'est pas grave si ils utilisent leur position pour virer la concurrence...
[^] # Re: pc libre ?
Posté par NickNolte . Évalué à 3.
Et puis, Intel, lui, fourni ses spécifications et est doté d'un pilote libre de grande qualité (même si on en a bavé, mais le 2.8 est extra).
AMD, ce sont les premiers cpu 64bits grands publiques.
AMD, ce sont des CPUs au rapport prix/performance supérieur, les Phenom II sont des tueries!
AMD, ce sont les specs complètes des chipset north et south bridge.
AMD, ce sont les specs complètes des cartes ATI (autre chose que de l'intégré d'Intel)
Dommage qu'ils sont juste à la bourre au niveau mobilité...
[^] # Re: pc libre ?
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 5.
Si je devais changer de carte aujourd'hui, j'aurai du mal a ne pas reprendre du Nvidia (je regarde des videos, j'utilise KDE4 avec les effets, le tout en double moniteurs DVI, et j'utilise le suspend. Ah oui, avec une carte silencieuse a radiateur passif.
Perso, j'aime récompenser les marques pour leur engagements pro libre, et AMD/ATi me plait pour les specs libérés, mais vu comment y'en chie au taf avec la carte ATI et les drivers (frglx ou radeonhd, peut importe), y'a des limites...
[^] # Re: pc libre ?
Posté par briaeros007 . Évalué à 3.
Et jamais modifier un quelconque fichier.
j'ai utiliser sgfxi, et d'après leur dire :
Other than that, the script is heavily tested, and is currently used something like 10k times per month, with almost total success.
Sinon, perso j'avais une nvidia, et je me suis aussi bien fait chier à la faire marcher , a attendre qu'ils supporte le 2.6 "oui mais pas tout de suite", etc....
bref pour moi ati ou nvidia, niveau installation c'est du pareil au même.
[^] # Re: pc libre ?
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 2.
Quand je parle des problemes, c'est apres, a l'utilisation !
[^] # Re: pc libre ?
Posté par briaeros007 . Évalué à 2.
[^] # Re: pc libre ?
Posté par _alex . Évalué à 2.
Avec ma GeForce 7600, la vidéo est accélérée, la 3D fonctionne, certes c'est difficilement comparable vu que c'est une carte non intégré sans truc tordu comme une sortie HDMI avec le son.
Au passage les multiples couches dans X ne sont pas simples à comprendre (celles pour avoir la 3D, celles pour la vidéo, celles pour la vidéo nouvelles versions, la partie Xorg, la partie kernel). J'ai fini par faire un petit memento pour m'y retrouver :
http://a.flament.free.fr/wiki/Xorg
[^] # Re: pc libre ?
Posté par briaeros007 . Évalué à 2.
(avoir _et_ le son _et_ la 3D sur une connectique, comparé avec "la 3D marche bien toute seule").
Ce qui serait interessant c'est "est ce qu'en utilisant une sortie classique (dvi/vga/...) la 3D marche aussi bien que sous nvidia ?
Là on pourrait dire que ati est moins fiable que nvidia, sinon on peut rien dire.
[^] # Re: pc libre ?
Posté par NickNolte . Évalué à 4.
Ce que c'est agaçant!!!
nVIDIA est jusqu'à présent le meilleur choix! Et je dis ça alors que j'ai pourtant donné ma 9600GT à mon ami pour garder mon HD4850 et ce tournant avec les pilotes radeonhd limités mais foncitonnelles, evidemment je me limite à du 1680x1050 et je n'utilise pas mon deuxième écran.
J'ai fonctionné 3-4 ans avec une Radeon Mobility T2 avec les pilots libres radeon et ce avec bonheur (support quasi complet bienque l'absence de specs), donc les pilotes libres, j'y crois!
Evidemment, je n'impose pas cela aux autres, je me fais violence à ne pas pouvoir profiter de l'accélération 3D/Video!
Car je n'ai jamais réussi à faire fonctionner "fglrx" et honnêtement, si je devais réussir après tous ces efforts, je refuserais malgré tout de les utiliser car c'est hallucinant qu'un pilote aussi vitale soit une chié à installer! J'ai une dizaine d'année de vol sous Linux à noté au passage!
Bref, le "jusqu'au boutisme" de l'enthousiasme linux faut arrêter! Car malgré toi, tu as plus vite fait d'induire les autres en erreur!
[^] # Re: pc libre ?
Posté par Sphax . Évalué à 2.
evidemment je me limite à du 1680x1050 et je n'utilise pas mon deuxième écran
Pourtant ça marche ça, je suis en 1920x1200 et un 2eme écran en 1280x1024, je le mets en place avec Xrandr à l'ouverture d'une session et ça roule.
Sinon, je suis d'accord, nvidia reste un meilleur choix pour qui veut profiter de sa carte sans s'emmerder. Personnellement j'avais acheté une ATI pour les jeux sous windows, alors je fais avec sous linux :p
[^] # Re: pc libre ?
Posté par briaeros007 . Évalué à -1.
Compare le proprio nvidia avec le proprio ati si tu veux prouver que c'est effectivement le "meilleur choix".
Sinon, tu as des arguments pour "c'est le meilleur choix" ou c'est parce que tu le dis que c'est vrai ?
Car je n'ai jamais réussi à faire fonctionner "fglrx" et honnêtement, si je devais réussir après tous ces efforts, je refuserais malgré tout de les utiliser car c'est hallucinant qu'un pilote aussi vitale soit une chié à installer! J'ai une dizaine d'année de vol sous Linux à noté au passage!
Pas de bol, pas eu de problèmes.
Par contre avec les premiers drivers nvidia y'avait une floppée de problèmes.
Tu as ressayé dernièrement ? et avec le soft que j'ai donné ?
Bref, le "jusqu'au boutisme" de l'enthousiasme linux faut arrêter! Car malgré toi, tu as plus vite fait d'induire les autres en erreur!
Désolé de m'appuyer sur des trucs qui "marche" et des sources un peu plus fiable (comme les retours de sgfxi etc...) que "ouinn j'ai aps réussi a l'installer, c'est que c'est qu'une grosse merde".
Si au moins tu disait _pourquoi_ , _quand_ etc... Mais non, on ne sait rien.
Si tu regardais aussi le forum nvidia et regardait le nombre de merde qu'il y a eu et qu'il y a ...
Bref, le nvidiot vs fanATIsme faut arrêter, et commencer à partir sur des trucs un peu objectifs.
[^] # Re: pc libre ?
Posté par briaeros007 . Évalué à 0.
[^] # Re: pc libre ?
Posté par NickNolte . Évalué à 2.
Installe UBUNTU, oui car que vous le vouliez ou non, c'est la plus accèssible et pourtant je suis un Debianneux (anciennement Gentooïste)!
Même avec cette distro ultra facile, faire fonctionné de façon stable une Radeon HD avec les pilotes fglrx sans mettre les doigts sans le cambuis fut un echec.
Le même système sans n'avoir rien fait d'autres avec une Geforce GT acheté,la demie-heure avant l'installation, a fonctionné du premier coup!
Je ne parle pas non plus du laptop de ma frangine qui tourne avec une ubuntu et une Geforce 8400GS qui n'a demandé aucune configuration si ce n'est de juste valider l'usage des pilotes proprios et de relancer X!
Ah sgfix? un truc tier à la distro et uniquement pour cette distro, qui nécessite d'être tout de même dans la confidence et simplement hors porté de l'utilisateur de base.
Bref, personne n'est contre toi, tu as pu faire fonctionner ta Radeon en full et c'est tant mieux, mais cela nécessite un effort intolérable!
Le binaire de nVIDIA nécessite queudalle.
ps: et je le rappelle, j'ai gardé mon ATI car je veux un pilote libre qui arrivera quand il arrivera malheureusement :p
[^] # Re: pc libre ?
Posté par briaeros007 . Évalué à 2.
Bon donc prenons une distrib connu pour sa fiabilité niveau "bon package".
Y'a qu'a voir la pollution des bug report pour kde4 avec ubuntu pour s'en convaincre.
Quand on veut critiquer une brique, on commence par utiliser un truc éprouvé et qu'on sait que ça ne genera en rien.
Pas par prendre le dernier truc pas stable pour ne pas savoir d'où viens le problème.
Même avec cette distro ultra facile, faire fonctionné de façon stable une Radeon HD avec les pilotes fglrx sans mettre les doigts sans le cambuis fut un echec.
Mais avec ma debian, je n'ai eu aucun problème.
Avec ubuntu , faire fonctionner un portable que j'avais fut un échec. J'ai installé debian, je n'ai eu aucun problème.
Mais c'est tellement facile de critiquer une brique en choissisant un système bancal, plutôt que de faire un travail sérieux d'investigation après tout.
Le même système sans n'avoir rien fait d'autres avec une Geforce GT acheté,la demie-heure avant l'installation, a fonctionné du premier coup!
avec les drivers nvidia ou pas ? Parce que là il y a un petit problème. rien que ramener la cg, débrancher le pc, le rebrancher, recup les drivers, arrêter le serveur X, lancer les drivers
et relancer le serveur X y'en a bien plus qu'une demi heure.
Et enfin tout ce que tu as prouvé c'est que sur TON ubuntu avec TON matériel, en utilisant le driver fglrx tu avais plus de mal qu'avec l'installeur nvidia.
Et ensuite tu ose dire que c'est reproductible par n'importe qui ? Alors pourquoi ce n'est pas reproductible sous ma debian sur mon matériel ?
Je ne parle pas non plus du laptop de ma frangine qui tourne avec une ubuntu et une Geforce 8400GS qui n'a demandé aucune configuration si ce n'est de juste valider l'usage des pilotes proprios et de relancer X!
Je parle pas de ma geforce mx 200 avec qui j'ai eu des emmerdes pas possibles, ni d'autres gammes.
Tu veux des exemples ou des contre exemple ? Je peux t'en trouver à tire larigot, ce n'est certainement pas ça qui déterminera si X est meilleur que Y.
Allez, vu que je vais me faire moinsser par des gens qui détestent qu'on ose combattre leur idée recu et taper sur nvidia :
Y'a la ps3 et la x360 qui combattent sur le terrain des consoles.
Je peux te trouver des gens qui n'ont eu aucun problèmes avec la ps3
Je peux te trouver des gens qui n'ont eu aucun problèmes avec la x360
Je peux te trouver des gens qui n'ont eu plein de problèmes avec la x360
Je peux te trouver des gens qui n'ont eu plein de problèmes avec la ps3
Qu'est ce qu'on peut en tirer ? Rien du tout.
Par contre
"54.x % des x360 sont retourné au SAV à cause du ring of death", là d'un coup ca permet de tirer des conclusions.
Bref basé des généralité sur _2_ exemples, quant bien même je te trouve 10000/mois contre-exemples visiblement ça te gêne absolument pas, mais moi si.
Bref, personne n'est contre toi, tu as pu faire fonctionner ta Radeon en full et c'est tant mieux, mais cela nécessite un effort intolérable!
Tu dis un truc, puis son contrairE.
tu veux dire lancer UNE ligne de commande, quant c'ets fglrx c'est un effort intolérable, mais quand c'est l'installateur de nvidia, c'est super simple.
WTF ? Et tu oses dire "personnes est contre toi" avec ça ?
Ah sgfix? un truc tier à la distro et uniquement pour cette distro, qui nécessite d'être tout de même dans la confidence et simplement hors porté de l'utilisateur de base.
Clair que chercher sur google et lire les 10 premiers liens c'est "être dans la confidence".
(quant à sgfxi il doit fonctionner sur toutes les debian likes).
Et installer un driver (nvidia ou fglrx) est de toute façon "hors de la porté d'un utilisateur de base qui découvre linux pour la première fois et qui est livré a lui même".
Il sait même pas c'est quoi, ni pourquoi installer un truc alors que son bureau semble très bien marcher.
Bref, avant de sortir des "non mais c'est trop compliqué pour le end user", déjà regarde si ce que TU fais correspond à l'utilisateur que tu veux défendre.
Enfin dire "non mais tu as osé chercher sur google" (et je n'ai pas parlé de l'install par module-assistant sur lequel tu trouve pléthore de howto pour les ubuntu like, et qui a très bien marché sur le laptop d'un copain) "c'est franchement intolérable", je crois que je vais te dire un truc qui va t'être encore plus intolérable.
la prochaine fois que tu as un problème, dis pas "bidule chouette est merdique" ,
RTFM
[^] # Re: pc libre ?
Posté par NickNolte . Évalué à 2.
Ensuite, si j'ai parlé d'Ubuntu c'est parce qu'au niveau reconnaissance de matériel automatique est l'une des meilleures distros, généralement je l'installe sur les machines des membres de ma famillles, de potes, de potes de potes car ça va bien plus vite qu'une Debian qui demande bien plus temps à peaufiner!
Et je leur installe GNOME pas un truc "inprogress" et tout laid comme KDE4 dont de lui d'ailleurs je n'ai vu marché correctement qu'au travers de clips sur "youtube"!
Ensuite dans google, je tape: install fglrx Debian "howto|tutorial"
Pas de "SGFXmachin truc" sur aucunes des 4 premières pages! Et généralement, je ne vais pas aussi loin dans les résultats sauf quand je suis super deséspéré!
J'ai même pour le coup, ajouté le mot clé "script" pour voir, pareil pas de sgfxi à l'horizon!
L'intolérable, c'est que le pilote fglrx demande un tas de manip pour que ça fonctionne, si ça fonctionne! Car moi, j'ai beau réussi à faire fonctionner une fois ce fameux module, il n'a pas tenu la demie-heure avant de partir en couille ( fenêtre qui lag, souris qui ne répond plus etc...)
Quant au 30 minutes, ne joue pas sur les mots, car de
1) tu ne sais pas où se trouve mon revendeur
2) tu ne sais pas si j'avais pas déjà téléchargé le pilote nvidia
3) tu ne sais pas si j'avais déjà retirer la carte.
Donc oui, FGLRX est merdique, ton script officieux et totalement inconnu sans doute que non mais le simple fait qu'il existe en dit long sur l'installateur natif de FGLRX.
Cela dit, je ne l'ai toujours pas essayé car je ne suis pas chez moi et même si ça marchait, ça ne prouverait pas que tu as raison car le succès ne dépend que de la connaissance de ce script!
Prend le temps de lire au lieu de t'exciter car tu te poses vraiment en gars "chezmoiçamarche!" ce qui te décridiblise alors que le problème de ce pilote de merde est connu et même reconnu dans ton script (lire les commentaires dans l'aide)
[^] # Re: pc libre ?
Posté par briaeros007 . Évalué à 2.
Ensuite dans google, je tape: install fglrx Debian "howto|tutorial"
Pas de "SGFXmachin truc" sur aucunes des 4 premières pages! Et généralement, je ne vais pas aussi loin dans les résultats sauf quand je suis super deséspéré!
J'ai même pour le coup, ajouté le mot clé "script" pour voir, pareil pas de sgfxi à l'horizon!
Faisons le test:
http://www.google.fr/search?q=debian+script+fglrx&ie=utf(...)
tu vois "debian script fglrx"
très compliqué comme recherche.
Maintenant regardons de plus prés le 7eme liens .
sgfxi manual page :: Debian install script for nvidia, fglrx, and .
Bref, je crois que c'est clair.
[^] # Re: pc libre ?
Posté par NickNolte . Évalué à 2.
Avec le mot script:
[http://www.google.com/search?hl=en&client=iceweasel-a&am(...) [+-]]
Crois-tu vraiment que "script" est un mot pertinent dans ce cas-ci?
[^] # Re: pc libre ?
Posté par briaeros007 . Évalué à 2.
Sachant que je cherchais un script d'installation de fglrx, oui je crois que c'était un mot clé pertinent...
# OSSv4
Posté par Aldoo . Évalué à 8.
En particulier, de nombreuses API (utilisées par des jeux ou autres applis) qui ont des problèmes à utiliser ALSA + Dmix comme backend et fonctionnent avec PulseAudio mais avec une latence à coucher dehors, n'ont aucun problème avec OSS.
Là je peux lancer des tonnes d'applis en même temps sans ajouter de latence sensible, ni même dégrader la qualité du son (pas de blips) ou accaparer le processeur.
Cependant, je me suis aussi tappé la lecture des commentaires du blog, ainsi que de nombreux liens qui y sont donnés, et je commence à être convaincu qu'OSS n'est pas la solution.
En vrac:
Problèmes qui pourraient être résolus avec plus ou moins de facilité:
- pas de support de la mise en veille (il faut relancer OSS quand on sort d'hibernation, ça fait tache :/)
- tendance des applis modernes à ne pas avoir de support pour OSS (j'utilise Phonon au travers de xine et pulseaudio sur OSS pour le son sous KDE... j'essayerai le backend VLC plus tard ; et kmix ne marche simplement pas)
- 2 gusses dans un garage, dont un au chômage, c'est un peu léger pour supporter un tel bouzin à long terme (solution : convertir les gusses d'ALSA... mouais difficile quand-même).
Mais surtout:*
- opérations flottantes dans le noyau pour le mixage
- en général trop de choses dans le noyau
- moins de possibilités qu'ALSA (ne me demandez pas les détails, c'est hors de mes compétences)
- paradigme dépassé et inadapté pour certaines situations (itou)
Alors je ne sais pas trop quelle est la vraie solution. Comme l'auteur du blog j'ai tendance à penser que PulseAudio ne sert à rien pour la plupart des usages. Je veux dire tant que j'ai du son et la possibilité de mixer les sorties sons de plusieurs applis sans me prendre la tête, je suis heureux.
Or c'est ce qu'est censé faire ALSA + Dmix. Dans ce cas, à quoi bon ajouter une autre couche, qui plus est, dans le cas de PulseAudio, une couche qui a tendance à prendre un paquet de temps CPU et ajouter un paquet de latence ? (la transparence réseau et le branchement à chaud sont des raisons valides... mais loins d'être une priorité pour l'utilisateur lambda que je suis).
Donc j'aurais tendance naïvement à penser que les applis devraient mieux supporter ALSA + Dmix… mais pour une raison que j'ignore, cela semble parfois difficile.
* : notez que je parle des pilotes OSS, et non pas de l'API OSS (le fameux /dev/dsp). Il est actuellement possible d'utiliser avec plus ou moins de bonheur l'API OSS sur ALSA (la fameuse émulation OSS), ou l'API ALSA sur OSS.
Je ne connais pas la difficulté de la tâche, mais améliorer le support de l'API OSS sur les pilotes ALSA (en particulier avec Dmix, ce qui ne marche pas à l'heure actuelle) pourrait résoudre de nombreux problèmes: API facile à utiliser pour les développeurs, avec toute la souplesse d'ALSA derrière.
[^] # Re: OSSv4
Posté par Sphax . Évalué à 6.
Par contre, je n'arrive pas à comprendre la réticence de certaines personnes sur ce journal au fait que le mixage se fasse dans le kernel et pas en userspace.
Après tout, le mixage c'est un peu comme l'accès au disque par plusieurs applications, là c'est aussi le kernel qui s'en occupe.
J'y connais pas grand chose, alors si quelqu'un peut détailler. Moi je file lire ce blog.
[^] # Re: OSSv4
Posté par Aldoo . Évalué à 2.
Parmi ces gens se trouvent, of course, les devs d'ALSA (ok, ils ne sont pas neutres), mais aussi Linus Torvalds himself.
Personnellement je veux juste que ça marche, ce qui est le cas actuellement, donc j'utilise OSS. Mais je ne ferai pas campagne pour son retour officiel dans le noyau ou son support par défaut dans les distribs.
[^] # Re: OSSv4
Posté par geb . Évalué à 2.
[^] # Re: OSSv4
Posté par Patrick Lamaizière (site web personnel) . Évalué à 3.
L'API est compatible OSS mais l'implémentation n'a rien à voir (sous FreeBSD, sais pas pour les autres)
les pixels au peuple !
[^] # Re: OSSv4
Posté par Patrick Lamaizière (site web personnel) . Évalué à 4.
Ben ici sous FreeBSD(*) ça ne choque personne, peut-être est -ce simplement pour le coté pratique même si c'est MAL. Et ça fait longtemps que ça existe, dans la 8.0 il y a même un equalizer.
(*) Mais bon ce sont des idiots incompétents qui jouent avec la VM.
les pixels au peuple !
# VRMS
Posté par Spack . Évalué à 2.
$ vrms
No non-free or contrib packages installed on logram! rms would be proud.
Ah merci ! Je ne connaissais pas VRMS mais c'est super comme logiciel... Cela permet de savoir quels sont les paquets non libres d'installés...
Bon je ne dit pas que je vais enlever tout ce qui n'est pas libre mais au moins maintenant je peux voir le degrés de liberté de ma distribution...
[^] # Re: VRMS
Posté par zebra3 . Évalué à 2.
$ vrms
Non-free packages installed on gcaron-portable
firmware-iwlwifi Binary firmware for Intel Wireless 3945, 4965 and 5000
unrar Unarchiver for .rar files (non-free version)
vmware-server-console VMware Server Console
Contrib packages installed on gcaron-portable
flashplugin-nonfree Adobe Flash Player - browser plugin
python-doc Documentation for the high-level object-oriented langu
python2.5-doc Documentation for the high-level object-oriented langu
ttf-mscorefonts-installer Installer for Microsoft TrueType core fonts
vmware-package utility for building VMware Debian packages
3 non-free packages, 0.2% of 1657 installed packages.
5 contrib packages, 0.3% of 1657 installed packages.
C'est quand même vachement difficile d'avoir un système 100% libre.
La plupart du temps, c'est pour l'interropérabilité, mais ne serait-ce que pour avoir du WiFi ou même simplement de la doc pour faire des scripts de temps en temps, on est dedans...
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.